stokes:Okay, thanks.
Transcript
stokes:Hello, everyone. Welcome to ACDC. This is number 169. It is issue 1790 in the P&M repo.
stokes:I dropped a link to the agenda here.
stokes:And, yeah, just by way of summary, so…
stokes:We'll touch on any Fusaka things,
stokes: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.
stokes: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.
stokes:But yeah, hopefully we can make good progress on the CL side today, and, you know, even pretty much, finalize things. So…
stokes: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.
stokes:Yeah, actually it was almost exactly 24 hours ago, so…
stokes:Pretty cool. Anyone have anything they'd like to share from there, or anything else on the other testnets?
stokes: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.
stokes:Okay, great. And have we started spamming blobs at the higher limits now?
stokes:Alright, hoodie.
kev and pandaops:We should have, but I can check the config.
stokes:Okay.
stokes:I'm not saying blog fees are going crazy, which…
stokes:Is that a good sign? Crazy good.
stokes:Emma, do you mean, like, they're going up, or they're jumping all over the place?
Ahmad Bitar | Nethermind:They're… they're high.
Ahmad Bitar | Nethermind:They're pretty high.
Ahmad Bitar | Nethermind:That's what I meant.
stokes:Yeah.
stokes:Okay.
stokes:Something we can look into.
stokes:Potus, would you like to mention the attestation issue?
Potuz:Not particularly, but… Okay.
stokes:Okay.
stokes:Then I'll reach out after.
stokes:Anyway, okay, there's some chatter about Hoodie.
stokes:Anything else, though? Generally, yeah, the test nights have gone really smoothly, and things look pretty good.
stokes:Okay. If not, then there was a request, and I wasn't quite sure where to put this, here from Holger.
stokes:So, he points out that BPOs don't have a place to live in terms of, like, EIPs or meta-EIPs.
stokes:And, you know, maybe to make, make the point, we have the current BPOs tied to the Fusaka Meta EIP.
stokes: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.
stokes: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.
stokes:With these changes. So, there's a question around how to think about this.
stokes: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.
stokes:I don't know if Holger is on the call today, but in any case, would anyone like to chime in further?
stokes:Or if you have any, yeah, any thoughts.
stokes:or strong opinions on how to do this. I think some kind of interfork MIDIP is probably the way to go.
stokes: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.
kev and pandaops: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.
kev and pandaops:And this is for the CLs, because they built the state on top of the last fork.
stokes:No.
stokes:So, then instead, would you just…
stokes: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.
stokes:Right.
stokes:Okay.
stokes:In any case…
stokes:There was some discussion on, the Execution Dev channel. Let me just paste this here in case someone wants to go find it.
stokes: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.
stokes:And yeah, Dustin, I think, is essentially lessening what Perry said about tying it explicitly to Fusaka, so…
stokes:Yeah, we'll figure that out before we get to…
stokes: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.
stokes:Okay.
stokes:Anything else on Fusaka?
stokes:Otherwise, yeah, mainnet is scheduled to arrive. What is that?
stokes:Basically, a little over 3 weeks.
stokes:So, that's super cool. And… Yeah.
stokes:Anything else? If not, we'll turn to Glamsterdam.
stokes:Okay.
stokes:Let me refer to the agenda.
stokes:Okay, I did want to start with a check-in on APBS, so, you know,
stokes:like I was saying, a big topic today is going through the rest of the Glencer Damn scope.
stokes:And selecting non-Hemliner EIPs, for the fork.
stokes: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.
stokes: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.
stokes: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
kev and pandaops:Trying to develop… Along with, Interop helps figure out a lot of those bugs earlier.
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.
Potuz: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.
Potuz: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.
Potuz:The one thing spec-wise that, that I wanted to mention is that we might have some changes, on the engine API,
Potuz: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.
Potuz:And depending on what happens with the scoping for Glamstadan, we have different options to what we can do on the engine API.
stokes:notes.
Potuz:Perhaps the major thing that I wanted to mention is that
Potuz: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,
Potuz: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.
Potuz:But, we were convinced that it's better to put it on the execution bid.
Potuz: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.
stokes:Anyway, thanks for the update.
stokes:To Perry's point…
stokes: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.
stokes:Okay.
stokes: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…
stokes:I think it might put some… some helpful boundaries on things, just to start the R&D process moving further along.
stokes:So… Yeah, let's… let's have those rough targets, having, you know.
stokes: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.
stokes:you know, around a month from now, mid-month December, and yeah, let's see how that goes.
stokes:Anything else there on EPVS?
stokes:If not, we can turn to the next section.
stokes:Okay, and before we jump in, I did put this here on purpose, just to drive the point home that, you know.
stokes:We should be very mindful of how we think about scoping, which is the thing we'll get into next.
stokes: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.
stokes: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,
Ryan Berckmans: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.
Ryan Berckmans: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.
Ryan Berckmans:And so, the downside risk here is that base chain or world chain may leave blobs for Alt-DA in the worst case.
Ryan Berckmans:And… I see the L1 and L2 model as being,
Ryan Berckmans: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.
Ryan Berckmans: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
Ryan Berckmans:Based on their growth trajectories.
Ryan Berckmans: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.
stokes:Okay, thank you.
stokes: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.
stokes:Kevin, Panda Ops,
stokes: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
kev and pandaops: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.
stokes:Okay, yeah, that's a good point, thanks.
stokes:Okay, yeah, as I suspect, things…
stokes:Might get a little animated as we go. Let's try to follow the agenda, just so there's a bit more sequence here.
stokes:And… In that case, okay. Let's,
stokes: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.
stokes: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.
stokes: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.
stokes: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.
stokes: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.
stokes:So yeah, I think that might be a nice way to do this.
stokes: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.
stokes:Maybe… here, let me just go in the order we have.
stokes: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:Yeah, since I posted it, so… I guess TLDR is dead.
terence:We're in favor of 80457688.
terence:For the 8071, we have the homework of just, like, understanding that
terence:Shorten the subjective year to 7 days,
terence: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
terence:8061 over 8071, for the reasons I mentioned in the description.
terence:But 8062, we're a little divided in a way that, like, not sure, like…
terence: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.
terence:because EPBS itself is already complicated, such that it will push your grams to then, mandate deadline to potentially end of next year, yeah.
stokes:Okay, thanks.
stokes: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.
stokes:Okay, thanks.
kingy_sigp:So yeah, so… for us, the TLDR is we…
kingy_sigp:we think the timing is… is right for FOCIL, and we don't think the…
kingy_sigp:We don't think the implementation will add too much, overhead, such that we should
kingy_sigp:really panic about being able to deliver, EVBS, but we acknowledge that
kingy_sigp: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.
kingy_sigp:So our position is basically do FOCIL.
kingy_sigp:Ascend FOCIL at the same time, and everything else, we hold off for hecker.
kingy_sigp:Except that we would like to see some…
kingy_sigp: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.
kingy_sigp:But yeah, that's… that's basically where we stand now.
stokes:Okay.
stokes:Thanks.
stokes:Let's see, next we had…
stokes:There is quite a bit of conversation here. Okay, I think next thing we have, Lodestar.
stokes: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.
Lodestar Team: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.
Lodestar Team: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
Lodestar Team: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.
Lodestar Team:And 8045 is a nice, simple
Lodestar Team:fix as well, so we would be okay with that. In regards to the remainder of the things, we have a different…
Lodestar Team: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
Lodestar Team:those maintenance EIPs more for an H-star fork.
Lodestar Team:And I don't see anybody
Lodestar Team:here that is nodding their head and no, so I think, what I said here represents our view at Lodestar.
stokes:Okay, thanks.
stokes:Nimbus. I was stumbling from Nimbus here that I would like to give an overview.
Dustin:Yes. Yeah. Sure, so… Broadly, so we… we support, 7688 as… as well. I mean, this is…
Dustin:And… for, essentially, the reasons that have been… have been described, I would note, that
Dustin: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.
Dustin:We also support 8045, this is…
Dustin:From our perspective, a fairly simple, straightforward bug fix in the spec.
Dustin:Yep.
Dustin:we… Support 8070, 81,
Dustin:Which, the reasoning there, essentially being that you have the consolidations that was, I mean, it's simply not an intended path.
Dustin: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,
Dustin: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.
Dustin:That is crazy. No. So, we have to just cut that off, from my perspective.
Dustin:So… things which lead to that kind of discussion, so… Anyway.
Dustin: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,
Dustin: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,
Dustin:The… it should… it's… implementation complexity should not be underestimated, and it's not only implementation complexity, but testing complexity.
Dustin: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
Dustin:issues pop up around, in the columns in Fugu, and what the gossip validation rules, and we are…
Dustin: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.
Dustin:What don't we support? We don't support 8061, which, weakens network security. We don't support 8062.
Dustin:Which is… the intu… the intuition is there, from the EIP proposer, but it's… it's a… it…
Dustin:Comes across as a bit of, ad hoc tweak.
Dustin:That's not otherwise well justified. So, kind of, I suppose, low risk, but also low reward on that one.
Dustin:We're not strongly against.
Dustin:Alright.
stokes:Okay, thanks. That was a nice overview.
stokes: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.
stokes:But would someone from TechU, like, to walk us through?
Enrico Del Fante (tbenr):Yeah, we just posted it, so let's start with the FOCIL,
Enrico Del Fante (tbenr):We think that… we acknowledge the fact that the FOCIL introduced
Enrico Del Fante (tbenr):Fair amount to complexity, and will probably slow down, the fork.
Enrico Del Fante (tbenr):But we also see, that this is really the time to consider it and, try to accumulate the timeline, accordingly, and, and,
Enrico Del Fante (tbenr):Try our best to… to put it in.
Enrico Del Fante (tbenr):So we are in favor of it.
Enrico Del Fante (tbenr):The other one, which we are in favor, is AT45.
Enrico Del Fante (tbenr):Simply because it's…
Enrico Del Fante (tbenr):pretty… a tiny change that makes sense to… to fix. And, we, have a low…
Enrico Del Fante (tbenr):low support for progressive containers, just because it's been…
Enrico Del Fante (tbenr):There for a long time, even if the,
Enrico Del Fante (tbenr):We have an implementation for stable containers, but we haven't looked into
Enrico Del Fante (tbenr):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.
Enrico Del Fante (tbenr):And we are also mildly, considering, AD.
Enrico Del Fante (tbenr):61, the churn limit.
Enrico Del Fante (tbenr):Definitely because the… the user experience
Enrico Del Fante (tbenr):Should be improved, for sure. And we are kind of natural on the other ones,
Enrico Del Fante (tbenr):We don't have strong opinions, for… for the…
Enrico Del Fante (tbenr):72 and 68, for instance, which…
Enrico Del Fante (tbenr):Are very tied to, fast finality things.
Enrico Del Fante (tbenr):And we don't have a… proper… Idea of the…
Enrico Del Fante (tbenr):The timelines, and how quickly these things do… needs to be done.
Enrico Del Fante (tbenr):That's us.
stokes:Oh yeah, thanks.
stokes: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:Yeah, the short, comment. So, so we really like, this, short cycles of, hot works, and because, now, we, we are
saulius:quite far from EPBS DevNet Zero, we would come with maybe not very popular opinion that cut everything and just leave EPBS,
saulius: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.
stokes:Alright, thank you.
stokes: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.
stokes:again, yeah, let me just go in order. So, first up I see here, the Stakers Union, they basically are here strongly supporting, FOCIL.
stokes:There's a comment on the agenda if you'd like to see more about that.
stokes:Next up, Caspar here from the rig team gave the rigs, the rig team's view on this.
stokes: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.
stokes:So, again, call out here to the rig view.
stokes: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.
stokes:And next, we have, Diva here, one of these, staking pools that was mentioned. Again, they're saying yes to 7688.
stokes: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.
stokes:And, yeah, Betty AP's good for that.
stokes:Let me see what else is here. Okay, I think that was more or less it, in terms of views for scoping.
stokes: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?
stokes:Okay, then we'll leave that there.
stokes:And… yeah, so Sophia has a comment here, which brings us to…
stokes:what I think, you know, it sounds like this is, you know, one of the big questions that we need to decide, so…
stokes:It sounds like there's, you know, some support for FOCIL, maybe some teams lean against.
stokes:And I think, again, this comes down to thinking about scoping, and the fork, and how we went to actually pull this off.
stokes:So… Yeah, would anyone like to present any views to, FOCIL itself?
stokes:I would have a suggestion myself for how to move forward, but yeah, maybe first we'll hear different,
stokes:Either arguments, or…
stokes:yeah, comments supporting or not supporting FOCIL and Amsterdam. And maybe before we jump into things.
stokes: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.
stokes: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…
soispoke:like, GF5 also, but then maybe include it in HTAR. And my take is that we… I don't really think, like.
soispoke:anyone can rely on statements about the next fork. Like, for me, it's really obvious that
soispoke: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.
soispoke: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…
soispoke:Yeah, I wanted to make a comment about that.
soispoke: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…
soispoke: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…
soispoke: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.
soispoke:And… yeah, I think, if I understand correctly, like, the main pushback against FOCIL has been around…
soispoke:fork cadence and fork scope, and complexity, which are all, like, valid arguments.
soispoke: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.
soispoke: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
soispoke: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.
soispoke: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.
soispoke: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.
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.
stokes: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.
stokes:in Gloucester Dam, and essentially move FOCIL then to Hecca.
stokes: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.
stokes: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…
stokes:what the issue would be, but…
stokes:In any case, we can keep talking about this.
stokes:Barnabe.
Barnabé Monnot:Yeah, hi. Well, I wanted to point out two things. The first thing is that
Barnabé Monnot: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.
Barnabé Monnot: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.
Barnabé Monnot: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
Barnabé Monnot:Ops and deployment teams are all thinking that this is just…
Barnabé Monnot: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.
stokes:Yeah, good point.
stokes: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.
stokes:So I do think on, you know, in that framing, we should lean towards less rather than more.
stokes: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…
Lodestar Team: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
Lodestar Team: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.
Lodestar Team: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
Lodestar Team:Not only schedule, development effort and being able to do research planning from a client team perspective, but also from a research perspective.
Lodestar Team: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.
Lodestar Team: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
Lodestar Team:For those in the industry and the market in order to understand what, what features are on the horizon.
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.
kev and pandaops: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
kev and pandaops: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.
kev and pandaops:One of my biggest fears with FOCIL, as well as EPBS, is that they change a lot of the same parts of the system.
kev and pandaops:Which means you cannot often make a change to EPBS without thinking about how this affects everything with FOCIL.
kev and pandaops:Same problem exists with, networking. Like Dustin said, same problem exists with testing. We can't test anything in isolation.
kev and pandaops: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.
kev and pandaops: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…
kev and pandaops: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.
kev and pandaops: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.
kev and pandaops:I also think that if we want predictable cadence and timelines, we're not going to be able to
kev and pandaops: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?
kev and pandaops:So yeah, I think our case is that if we want to keep testing
kev and pandaops: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.
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.
Caspar Schwarz-Schilling:like, in particular, shorter slots in FOCIL, both being CL changes, and then the worry being that,
Caspar Schwarz-Schilling:For similar arguments regarding, fork cadence and, and kind of…
Caspar Schwarz-Schilling: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
Caspar Schwarz-Schilling:for, like, a credible commitment, for FOCIL being prioritized in HECA.
Caspar Schwarz-Schilling:Over other changes, if necessary. And yeah, so I guess, I think.
Caspar Schwarz-Schilling: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.
Lodestar Team:Like, being able to say what is the priority of the 6 seconds loss versus FOCIL is important.
Lodestar Team: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.
Lodestar Team: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.
Lodestar Team: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.
stokes:Metallic.
vitalik: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,
vitalik:Also a social system. And so, if,
vitalik:we have goals, that we, care about. We, need to continually make them clear to…
vitalik: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…
vitalik:Either, like, making some type of commitment to
vitalik:FOCIL, which, I think, you know, there was, a good point made, right, which is, that, it's, like, it could happen in,
vitalik: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,
vitalik:An actual risk that's, basically, you know, if the community perceives us as continually, delaying certain kinds of things, but,
vitalik: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,
vitalik:Like… Basically, yeah, even…
vitalik: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,
vitalik:Censorship resistance and decentralization, and, you know, being able to say things like, okay, you know, we've done,
vitalik:Scale-related life related things for the last three. And,
vitalik: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…
vitalik:be willing to make commitments, that, last, not that…
vitalik:that go further out than one fork, and that at the same time are not absolute, but that are also… also meaningful. And,
vitalik:And this is, like, the… yeah, like, I don't think there's,
vitalik: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,
vitalik:If there's strong agreement that something is, is valuable, then when is it getting included?
stokes:Yeah, that's helpful context, thanks.
stokes: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.
Sophia Gold:to launch an optional, ZKEA tester client.
Sophia Gold:But also, I would be concerned if, a FOCIL is delayed past, the H fork.
Sophia Gold:And the reason is that I see FOCIL as actually part of our scaling roadmap.
Sophia Gold: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.
Sophia Gold:Because, you know, I think with multiple proofs that we need for security, I don't see the possibility of,
Sophia Gold: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…
Sophia Gold:factor that… project out, factor that in, and the possibility of fork delays, I would be concerned if FOCIL… that that FOCIL would
Sophia Gold:could possibly block that if it's bunked out of the HFERG.
Sophia Gold:So, I am skept… I am sympathetic to people who are skeptical of,
Sophia Gold: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.
stokes:Okay, thanks.
stokes:Any other… Present comments?
stokes:Okay, so let me try to play this all back.
stokes:it sounds like people, I think, mostly are okay with…
stokes:doing something like FOCIL and HECA.
stokes:If we have a way to credibly commit to it.
stokes: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.
stokes: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?
stokes: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.
stokes:So, that's what I would propose as the path forward on this one.
stokes:Then the question is, how do we credibly commit to it?
stokes:I'm open to ideas.
stokes:one would even be going ahead and SFI FOCIL for HECA. The meta-EIP.
stokes:Is on the way.
stokes:So we could just do that.
stokes: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.
stokes:I assume unilaterally. It sounds like it's unilateral?
stokes:But in any case, basically say, hey, this is definitely happening.
stokes:And, ultimately, people just take us at our word. And the reason they can do that is because, yeah, you know, I think…
stokes:The sentiment today, the people today, will still be here for the most part.
stokes: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.
Lodestar Team:Is great.
stokes:Right.
stokes:So, yeah, do you have any thoughts then? Like, should we SFI?
stokes: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.
stokes:And find the right way to do this.
Lodestar Team:I mean.
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…
Lodestar Team: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
Lodestar Team:Because it took us… and granted, it's a maturation of the process, so it's not to discount the process, but…
Lodestar Team: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
Lodestar Team: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,
Lodestar Team: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.
Lodestar Team: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.
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.
Potuz: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.
Potuz:Now, which sounds already another Pandora's box.
Potuz: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.
kev and pandaops: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.
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.
soispoke:You know, discussions around FOCIL have, like, happened already.
soispoke: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
soispoke: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.
stokes:Kevin Penhops, was your hand slow?
kev and pandaops:Sorry, that was a mistake.
stokes:Okay, okay.
stokes: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.
Lodestar Team: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?
Lodestar Team:Well, maybe not, so we can push it back to the next one, but then…
Lodestar Team: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.
Lodestar Team: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.
stokes:Okay, thanks.
stokes: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.
stokes:Then in terms of moving forward, I think what we should do is take all this contact for FOCIL.
stokes: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.
stokes: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.
stokes:That could look like, you know.
stokes: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.
stokes:it could look like something else. So, there are some options here.
stokes:And… yeah, I think that'd be a nice way forward.
stokes: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.
stokes:So… Does that sound good to everyone?
stokes:So, essentially, yeah.
stokes:keep all this context in mind for FOCIL. Let's try to find a way to think about how to get it into ECA.
stokes:we'll sort that out two weeks from today on the next ACDC, and then we'll move forward with the other EIPs today.
stokes:Okay, then let's do that.
stokes:Then in that case, let's turn to the other EIPs.
stokes:Sorry, I saw this comment here from Kingi for delaying FOCIL… Okay.
stokes:And I guess the other thing is, you know.
stokes: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.
stokes:We'll need another call to get to the final sales scope for Amsterdam.
stokes: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.
stokes:So we could touch on those today.
stokes:Yeah, again, we can think more about it and do this, because I agree.
stokes: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.
stokes:I'm not sure.
stokes: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.
stokes:FOCIL, and what it sort of really stands for is very important to Ethereum.
stokes:But there's a lot of things to fit together here.
stokes:So, let's look at the other EIPs, and…
stokes:Yeah, I'm not sure how we want to go about this.
stokes: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.
stokes: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.
stokes: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.
stokes:I could also frame it as support for 8068. This is the one that changes the effective balances line a bit.
stokes:And I believe the intent is to make it, essentially.
stokes:Have, like, a more even playing ground between 01 and 02 validators.
stokes: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,
Anders Elowsson:Yeah, so there's an interaction, essentially, between 8068 and 8062, so we're… Yep.
Anders Elowsson:Thinking about if we can sort of,
Anders Elowsson:Compensate for the, you know, the lower… the lower yield that you get on a…
Anders Elowsson: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,
Anders Elowsson:So we don't do 80-68, but we have 80-62, which is a slightly stronger fee.
Anders Elowsson: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
Anders Elowsson: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.
Anders Elowsson:On a compounding validator, so there's this option to just do that as well.
Anders Elowsson:But anyway, I see that the complexity of 8068, it seems like there's, like.
Anders Elowsson:To do the whole thing where you change the, you know, the affected balance bands, it seems like it might be off the…
Anders Elowsson:Yeah, out of scope, as it seems. I don't know. I'm not sure about how people feel about it.
stokes:Agree.
stokes: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.
Potuz: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
Potuz: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.
Potuz: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
Potuz: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,
Anders Elowsson:you know, node operators living on 32-it validators will consolidate, even without some
Anders Elowsson: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.
Potuz: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
Potuz: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.
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.
Greg K | Lido: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.
Greg K | Lido:And yeah, from the LIDAR side, LiDAR is working towards having
Greg K | Lido: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.
Greg K | Lido: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.
Greg K | Lido:So we think that, it's unfair having a penalty, because, you know, we have this fixed bond requirement, we provide this very cheap
Greg K | Lido:Very low barrier to entry, for also stakeholders.
Greg K | Lido:And, yeah, like, adding some cost for those 01 validators.
Greg K | Lido: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.
Greg K | Lido: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.
stokes:Okay. Yeah, thanks for the, input.
stokes:So… Okay, I think we can at least, in terms of making progress through the scoping discussion.
stokes: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.
stokes:But I think we can at least do that today, so…
stokes: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.
stokes:Agree.
stokes:So, let's go ahead and do that.
stokes:And we touched on 8062,
stokes:Yeah, I don't know if there's more to say here.
stokes: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.
stokes:Let's try to go through these other…
stokes:staking EIPs, that touch the staking mechanics. So we have 8061 and 8071. So, 8061, this is the IP that, touches various turn limits.
stokes:8071, this is preventing consolidations as withdrawals, which, patches this, essentially consequence of Petra. So…
stokes: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
kev and pandaops: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…
kev and pandaops:either DFI or SFI, all the remaining CLIPs in today's call.
Potuz:Please know…
stokes:Yeah, I agree, Barnabas, with the spirit, I think, especially given that
stokes:you know, this FOCIL, the way we want to handle FOCIL, is possibly somewhat novel.
stokes:I think at least one more call is justified.
stokes:Okay.
stokes:Any comments on AD61 or 8071? .
Francesco:Yeah, I mean, I can just say…
stokes:work soon. Oh, sure.
Francesco: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…
Francesco:basically, state growth and all those, like, issues kind of getting worse as we increase the activation churn, so I've decided to not,
Francesco: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,
Francesco: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.
Francesco:Obviously, like, 71 is a much, much simpler EIP, but it's also trying to do much less. It's trying just to address
Francesco: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.
stokes:I think we're okay about it. But yeah, that was helpful context. So…
stokes:Right, I would be curious then to hear from client teams if they'd had a chance to look at 8061.
stokes:And enough depth to get a sense of, yeah, like, because it sounds like 8061…
stokes:would be superior to 8071, but the concern then would be, you know, it's a much bigger EIP, or at least big enough.
stokes:Do client teams agree with this assessment that 8061 is big enough to have some reservations?
stokes: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.
Potuz: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.
Potuz: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
Potuz:are being unfairly treated by the current system will be even in a worse situation after we put 8071.
Potuz:And,
Potuz: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.
Potuz:But it's not that much higher. I mean, we're already, like, Looking into EPBS?
Potuz: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.
stokes:Francesco?
Francesco: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…
Francesco: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.
Francesco: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
Francesco:On what the impact on the week's subjectivity period is, or on, like.
Francesco: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,
Potuz:Treatment of what is the…
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:7 days.
stokes:7 News? Okay.
stokes:Okay, so, like, a week.
stokes:Which does mean there are other places where we have 7-day windows like this.
Francesco: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,
Francesco: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…
Francesco:I'm not sure exactly, like, how to get to this answer.
stokes:Okay.
stokes: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.
stokes:And… okay. Then, let's turn to 8045. This is the EIP that would exclude slash validators from the proposer sequence.
stokes:Yeah, so I think where this really comes up…
stokes: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?
stokes:Again, I haven't had time to get a good pulse of the differing client opinions.
stokes:I think some people were forced, some people were more neutral.
stokes: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.
stokes:Potus?
Potuz:I just have one little grudge with DCIP, and…
Potuz: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.
Potuz:But DCIP changes this, because you now need to also have the same slash validators, and those can change, intra-epoch.
Potuz: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.
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,
Potuz: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.
Potuz: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.
Potuz:But, if we add the CIP, this is going to be impossible.
Potuz:Yep.
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.
stokes:Okay.
stokes:Okay.
stokes: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.
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…
stokes:Yeah, again, it is actually a pretty small change, something we can test very easily, and yeah, would be good to have.
stokes: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.
stokes:And I'll just comment, yeah, seems like…
stokes:people lean towards including it in Glamstra.
stokes: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.
stokes:This is adding stable containers, as it's featured as a ZSpec.
stokes: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.
stokes:Again, this is a very nice quality of life improvement, for people using that part of the spec and the protocol.
stokes: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.
stokes: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
stokes:Is it gonna move the needle that much? This is a debate we can have.
stokes:And, yeah, would anyone like to add some comments, on this one?
stokes: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…
stokes:You know, that's… That's a much heavier process than just, say, a spec change.
stokes:Okay. Came in here in the chat, says it's nice to have.
stokes:But nice to have is not necessary to have.
stokes: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.
Greg K | Lido:So, yeah, there was also a post of, Dmitry in the PR of the previous, ACD call, but, yeah, it's,
Greg K | Lido: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.
Greg K | Lido:So I will post also here the link of the previous methods.
stokes:Okay.
stokes:Anyone think we should defer 7688?
stokes:Again, I don't have all the client team opinions handy.
stokes:But I do recall there was, yeah, mixed support.
stokes:Okay, then in that case, I think we move ahead as follows, so…
stokes:Yeah, the intent was to get through as much of this today as we could.
stokes:there's a lot to cover, so, you know, that is what it is. We also do… do have time.
stokes:We should settle Glenstrom scope in November, but that means we have at least one more call on the CL side to discuss this.
stokes:I also think, given FOCIL and all the considerations there, it does make sense to take another call, so let's do that.
stokes:So, just to be clear, we will make final…
stokes:CFI, DFI decisions on the CLEAPs on the next call, so two weeks from today.
stokes:So, I think, again, with this context today, this helps people refine their client views, and let's, yeah, keep doing that.
stokes:Let's get to final versions by the next ACDC.
stokes:And the big thing in parallel will be sorting out, how to make this credible commitment to FOCIL.
stokes:Please, if someone has, you know, an idea here, feel free to propose. I will also propose some things, and…
stokes: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,
stokes:That have been made, just to see what makes sense.
stokes:Otherwise, we'll need to, find the best option two weeks from today. And…
stokes:Assuming we do that, then we'll have a path towards FOCIL and H-star.
stokes:We'll go ahead and pick some number of these other EIPs for Amsterdam.
stokes:One thing we can't say that we did today was, DFI 8068.
stokes:for Amsterdam, so that's some good progress.
stokes:And then otherwise, yeah, we'll keep moving things forward on the next call.
stokes:Francesco?
Francesco: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.
stokes:It seems fine to me. I don't know. Does anyone have an issue?
stokes:It was kind of just an evolution of 61.
stokes:And or 71. Like… I, I think…
Francesco:It's like.
stokes:You know, pardon.
Francesco:of 7061 right now, basically. Right.
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.
stokes:Whereas this is just, you know, a refinement of things that, you know, we're already talking about, so seems perfectly fine to me.
stokes: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…
stokes:So yeah, I mean, this is one option, is we do actually just start discussing H-star headliners.
stokes:I'm not sure if we would necessarily want to do that, but it's an option.
stokes:I would personally start to think about ways just to credibly commit to FOCIL and H-star.
stokes:Via, you know, whatever process mechanism makes sense.
stokes: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.
stokes:I can try to reach out to some of the 6-second slot authors of the EIP, and yeah, try to fill it out.
stokes: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.
stokes:So yeah, I can be in touch with everyone, and we'll find the right path forward here.
stokes: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.
stokes:And… yeah, I'll see you all around.
stokes: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…
stokes:See you there, if you can make it, and if not, see you next time on ACD.
stokes:Goodbye.
Potuz:Bye-bye.
Carl Beekhuizen:Thanks, Paul.
Chat Logs
00:02:56
stokes:https://github.com/ethereum/pm/issues/1790
00:04:32
Ahmad Bitar | Nethermind:Blob fees going crazy on hoodi
00:04:49
Potuz:we could mention the attestation issue
00:05:19
kev and pandaops:Blob base fee:
379718 wei doesn’t seem that high?
00:06:46
Ahmad Bitar | Nethermind:Replying to "Blob base fee:
37971..."
I see 0.2759 Gwei on hoodi.blobscan.com
00:08:07
Dustin:they have to be tied to Fusaka explicitly somehow
00:08:22
stokes:#execution-dev
00:08:44
nixo:Replying to "#execution-dev"
https://discord.com/channels/595666850260713488/688075293562503241/1437751005293973536
00:10:15
Ryan Berckmans:gm, I'm a guest today to remark on headliner EIPs for Glamsterdam.
00:12:07
kev and pandaops:Cool let us know as soon as we can start helping! Can we target end of nov?
00:12:27
terence:dont think the engine api changes need to be the first devnet though
00:12:35
Anders Elowsson:Replying to "gm, I'm a guest toda..."
Are you referring to ePBS and BALs?
00:14:05
Ryan Berckmans:Replying to "gm, I'm a guest to..."
I'm here to argue for Glamsterdam to ship ASAP to unlock additional blob scaling ASAP, and therefore for the exclusion of FOCIL from Glamsterdam.
00:15:19
terence:only headliner or only eip?
00:15:45
soispoke:Frontrunning the agenda I guess
00:15:49
Potuz:This is most probably about FOCIL only so probably it could go after discussing all the other EIPs cause FOCIL will surely be a contentious thing that will take over the meeting
00:15:51
Trent:Replying to "only headliner or on..."
Only CL headliner
00:16:10
stokes:Replying to "This is most probabl..."
You want to cover the others first?
00:16:10
Potuz:we have a bunch of EIPs to discuss, can we go through them before?
00:16:17
stokes:Replying to "This is most probabl..."
I could see either way, sequence wise
00:16:18
Łukasz Rozmej:Replying to "This is most probabl..."
I came for FOCIL and you tell me I have to wait more? No fair!
00:16:32
Potuz:Replying to "This is most probabl..."
I suspect if we open the can of FOCIL we won' t advance at all today, we probably want to do the others first
00:16:57
terence:Maybe a good starting point to discuss is do we want glamseterdam shipping to be constrained by a deadline?
00:17:03
Francesco:What’s the point of discussing the other EIPs without having made the most consequential decision?
00:17:10
Sophia Gold:doesn't this depend on the ptc deadline? i haven't checked the spec in a bit: do we currently even get blob scaling?
00:17:14
Ryan Berckmans:Thank your your time today. Have a good call.
00:18:04
Potuz:Replying to "What’s the point of ..."
all the other EIPs are kinda irrelevant with respect to adding or not FOCIL
00:18:53
Sophia Gold:Replying to "doesn't this depen..."
just to be clear, i like a 4s ptc deadline for the extra proving time
00:21:15
Potuz:Replying to "doesn't this depend ..."
I think there' s broad consensus on dual deadlines and on setting the deadlines later at testing time
00:21:38
Potuz:Replying to "doesn't this depend ..."
at any rate we will have dual deadlines in the spec and the option to set them at the same time if needed
00:22:51
Sophia Gold:Replying to "doesn't this depen..."
if people aren't concerned about the free option, obviously dual deadline is best
00:23:33
kev and pandaops:2w sounds very optimistic. IMO we can barely do engineAPI changes in 2w cadence even when it doesn’t touch more than one EIP.
00:24:23
NC:Replying to "2w sounds very optim…"
I think we are only speaking about engineering effort
00:25:14
Potuz:Replying to "doesn't this depend ..."
we are concerned, so we want to set them as soon as possible given the blob count, and presumably do something similar with the payload depending on gas limit or payload size for example
00:26:00
kev and pandaops:Replying to "2w sounds very optim..."
Yeah but that’s usually not compressed in one stretch and often interlaced with PR reviews and getting input from a wider range of audiences. Barely any EIP can be done in a 2w timeline extension to the overall fork tbh, let alone a big one.
00:28:33
Sophia Gold:Replying to "doesn't this depen..."
i see. i know it was suggested to have them be dynamic but didn't know that was being seriously considered
00:29:01
NC:Replying to "2w sounds very optim…"
@kev and pandaops yea I understand, there’s additional effort for spec writing and reviewing. I think the 2 weeks refers to additional time spent provided epbs and focil are implemented, and the related spec and test infrastructure is ready
00:29:29
Potuz:Replying to "doesn't this depend ..."
it doesn't need to be in Glamsterdam and it is not a hardfork so it's easy to test and implement after the fork
00:30:01
Potuz:Replying to "doesn't this depend ..."
having the deadline be dependent on the payload size or the number of KZG commitments is trivial to implement and ship, probably harder to test and set the right parameters
00:30:36
Potuz:Replying to "doesn't this depend ..."
but anyway is also trivially gameable for a builder that wants to exercise the free option so it's not a solution at all
00:31:19
Anders Elowsson:What’s the complexity diff on 8061 vs 8071? Purely from a dev perspective, ignoring the weak subjectivity analysis.
00:32:17
soispoke:Ok so summary for FOCIL:
3 teams explicitly want to SFI it
2 teams expressed conditional support (as in support with caveats, mainly around fork complexity and timelines)
1 team would rather DFI it
00:32:22
Potuz:8061 is a bit more complex, 8071's changes are localized it should be much simpler to deploy and test
00:32:26
Dustin:Replying to "2w sounds very opt..."
So if FOCIL has already implemented, then it takes 2 weeks, that's the intent? I think the idea is, from a baseline of no FOCIL
00:32:30
Caspar Schwarz-Schilling:RIG view: https://notes.ethereum.org/@css/rig-glamsterdam
00:32:34
Dustin:Replying to "2w sounds very opt..."
Because that's the alternative
00:32:42
Barnabé Monnot:Should we add tweets to the record? https://x.com/barnabemonnot/status/1988202114657505428
00:33:01
terence:Replying to "2w sounds very optim..."
FOCIL on top of fulu is different than FOCIL on top of epbs too
00:33:02
kingy_sigp:Replying to "What’s the complexit..."
8071 is basically just if >2048 dont allow consolidation
00:33:03
Francesco:Replying to "8061 is a bit more c..."
It’s also much less useful
00:33:27
Sophia Gold:Can we discuss whether we think we can credibly commit to scheduling FOCIL for the H fork?
00:33:33
Potuz:Replying to "8061 is a bit more c..."
yeah my preference is 8061
00:33:42
Dustin:Replying to "2w sounds very opt..."
Yeah, has it been rebased yet?
00:33:46
Dustin:Replying to "2w sounds very opt..."
It's not real until it has
00:33:51
soispoke:Replying to "Should we add tweets..."
https://x.com/soispoke/status/1988250897437052934?s=20
00:34:06
Trent:Will the testing and panda teams give their perspective on complexity of SFIing FOCIL?
00:34:14
Potuz:Replying to "8061 is a bit more c..."
I think 8071 is the worst of both worlds: we not only don't use the consolidation churn for useful things like exits, but also make exits worst for everyone
00:34:31
kev and pandaops:Replying to "2w sounds very optim..."
+1 I think we’re realistically talking about a fork 3-6mos later if we add focil in vs not.
00:34:51
kev and pandaops:Replying to "2w sounds very optim..."
And this is optimistic, assuming specs don’t churn much
00:35:26
terence:Replying to "2w sounds very optim..."
I think adding focil pushes the mainnet date to end of next year, so it's more important to discuss whether time line is a constraint. If we agree it's not then let's add focil
00:35:33
Mario Vega:EIP-7805 EL spec testing complexity assessment here: https://github.com/ethsteel/pm/blob/main/complexity_assessments/EIPs/EIP-7805.md#checklist
Tldr, not the end of the world but complexity mid/high nonetheless. This plus BAL + Gas repricing is way too high compounded complexity in our opinion.
00:35:48
Dustin:Replying to "2w sounds very opt..."
Yeah, this is our position
00:35:55
kev and pandaops:IMO we shouldn’t include focil because of fear. We should include it because it’s a good feature and we need it. If we do, then we need to accept that theres a chance of no fork in 2026.
00:36:28
nixo:i will say a wallet dev and andrew coathup chimed in on community feedback (in addition to the already-mentioned stakers union): https://ethereum-magicians.org/t/community-feedback-on-non-headlining-features-in-glamsterdam/26410
on the CL side: support for 8045, 8062, 8068 on a B-tier
support for pushing FOCIL to Heka from abc, with strong support for it in Glammy from Stakers Union. Wallet dev only had an opinion on an EL EIP
(no need to speak, pretty straightforward)
00:36:49
Greg K | Lido:Replying to "Screenshot 2025-11..."
8062 is an unfair penalty for 0x01 validators, while 8068 gives sound incentives to switch from 0x01 to 0x02, why is 8062 considered a better choice?
00:36:58
Barnabé Monnot:Replying to "EIP-7805 EL spec tes..."
“This analysis has only been done for execution layer clients. The impact on CL clients will be much greater.”
00:37:44
Toni Wahrstätter:Replying to "[Full message cannot be displayed on this version]"
0x1 cost resources (e.g. data and compute) but don't pay for it.
00:37:52
Francesco:I don’t think it’s as black and white as “if we don’t SFI FOCIL we’re saying that fork cadence is the only thing that matters”
00:37:56
NC:Replying to "IMO we shouldn’t inc…"
If we want epbs, focil, 6s slot by the end of next year, then how does epbs + focil alone already take the whole year? Or we just do epbs + 6s slot by end of next year?
00:38:31
soispoke:Replying to "I don’t think it’s a..."
It’s the main argument though, everyone seems to agree FOCIL is important as a feature in itself
00:38:50
Anders Elowsson:Replying to "Screenshot 2025-11-13 at 09.18.50.png"
8062 is not necessarily unfair given that 0x02 already pay substantially for their withdrawals and that 0x01 skim withdrawals also cost resources which are not paid for. 8068 would be nice but we argue that we can try to compensate by doing 8062 a bit stronger to get a simpler change cover for both.
00:38:52
soispoke:Replying to "I don’t think it’s a..."
So if it’s not about the feature itself it’s about fork complexity or fork cadence
00:39:06
kev and pandaops:Replying to "IMO we shouldn’t inc..."
I think we can do bal + epbs -> June/aug. 6s + focil -> jan/march realistically.
00:39:15
Greg K | Lido:Replying to "Screenshot 2025-11..."
Do 0x02 pay for skimming beyond 2048?
00:39:25
Trent:Can some of the testing or panda team speak on audio, not chat?
00:39:26
Francesco:Replying to "I don’t think it’s a..."
Many things are important, doesn’t mean we should do them all at once
00:39:31
kev and pandaops:Replying to "IMO we shouldn’t inc..."
Doing all: bal/epbs/6s/focil in 2026 is a pipe dream if we’re being honest with ourselves.
00:39:34
Mehdi Aouadi:FOCIL in H fork with 6s slots will present the same issue we have today with ePBS
00:39:50
Potuz:Replying to "FOCIL in H fork with..."
yeah this is my main fear of delaying FOCIL
00:39:55
lightclient:Every fork adds risk too
00:40:17
Anders Elowsson:Replying to "Screenshot 2025-11-13 at 09.18.50.png"
No I was referring to partial withdrawals
00:40:19
soispoke:Replying to "FOCIL in H fork with..."
exactly
00:40:59
lightclient:It’s just not possible to make commitments that far in advance
00:41:05
soispoke:Replying to "I don’t think it’s a..."
Sure, I don’t think this contradicts what I said
00:41:06
lightclient:We don’t know what we’ll need to do in 18 months
00:41:12
Potuz:We are doing exactly that: we are doing N+2 right now before shipping N+1
00:41:21
Toni Wahrstätter:CR is important and focil, giving us better inclusion guarantees, is a strong proposal but I'd be against making the fork larger at this point, recognizing that ePBS is already big enough.
I don't think we should commit to anything re h* today/soon.
00:41:57
NC:Replying to "CR is important and …"
Focil will be the new verkle or eof that’s what people fear I think
00:42:07
kasey:Replying to "FOCIL in H fork with..."
However focil and epbs both include changes to fork choice / STF and new messages/topics as Dustin highlighted. So there are more possibilities for testing interactions between focil and ebps; 6s and focil seem more orthogonal to each other.
00:42:08
Toni Wahrstätter:Replying to "CR is important and ..."
No i don't think so
00:42:30
Justins iPhone:i dont want to repeat the same mistakes as EOF either
00:42:34
Lodestar Team:Replying to "We are doing exactly..."
We say that with N being Fusaka, so we mean having guarantees for Heka today also for say, FOCIL
00:43:05
Dustin:Replying to "CR is important an..."
If one abstracts from "Verkle" to "statelessness", statelessness just evolved
00:43:08
Potuz:Replying to "We are doing exactly..."
oh so you want to plan the next 3 forks? good luck with that, we can barely scope the next one
00:43:47
Lodestar Team:Replying to "We are doing exactly..."
Yes we have been poor at those commitments historically
00:43:48
Francesco:Replying to "CR is important and ..."
Strong agree, the equivalent here would be if we just decided that we want to do something different than focil (but with the same goal), which would be fine
00:43:52
Greg K | Lido:Replying to "Screenshot 2025-11..."
Yep so the same resource (auto sweeping algo) is charged for 0x01 but not for 0x02, this is an asymmetry, which I can not see how can be rationalized.
This hurts trust-minimized permissionless staking such as Lido CSM and Rocket Pool, which rely on 0x01 (fixed bond requirement)
00:43:53
Łukasz Rozmej:Replying to "CR is important and ..."
@Dustin but shipped is better than perfect ;)
00:43:55
Stefan Bratanov:Replying to "We are doing exactly..."
We can also ship just FOCIL in H* relatively quickly after ePBS, and leave 6s for I*
00:44:08
Francesco:Replying to "CR is important and ..."
Plus don’t get the verkle argument anyway because the complexity compared to focil is way different
00:44:10
Ansgar Dietrichs:Personally, seeing how passionate everyone here is about FOCIL, I don’t worry at all that delaying it would risk us never shipping it (or some future variant).
Ironically I would be much more in favor of shipping it now if there was less enthusiastic support for it (because that would make me worried for the future otherwise)
00:44:12
Toni Wahrstätter:Replying to "CR is important and ..."
Completely separate things and yeah, if we have an even better CR solution in 6 month, good. I don't think that will be the case. FOCIL is the result of years of research and it feels like the design space has been explored with FOCIL being the best we got to.
00:44:27
Potuz:Replying to "We are doing exactly..."
that would be my preference for sure, probably no chance of that happening though
00:44:59
Dustin:EOF had a different issue: to brutally shortly and subjectively summarize a long debate, it was a victim of did people even want it. And that doesn't seem likely for FOCIL. it's a qualitatively new feature set
00:45:04
Łukasz Rozmej:There is always new shiny thing….
00:45:11
soispoke:Replying to "Personally, seeing h..."
Ship things people are not enthusiastic about is also a bit odd but I think I see what you mean
00:45:17
stokes:Its different bc of how core it is to atheneum’s values
00:45:21
vitalik:I have one thing to say (sorry hand raise not working in browser)
00:45:30
stokes:Replying to "Its different bc of ..."
ethereum
00:45:46
stokes:Replying to "I have one thing to ..."
After lodestar!
00:45:47
kingy_sigp:if the inertia here is FOCIL to Heka - that changes our appetite for some of the other EIPs. Generally, we're in favour of more targeted, shorter cadence hardforks - but acknowledge there is widespread community support for FOCIL
00:45:47
Anders Elowsson:Replying to "CR is important and ..."
We have FOCILR in EIP-8046 which extends on FOCIL. FOCILR offers strong censorship resistance. But that extension means we still benefit from shipping FOCIL first.
https://eips.ethereum.org/EIPS/eip-8046
00:45:57
Toni Wahrstätter:Replying to "Personally, seeing h..."
Complexity piles up though. No matter how enthusiastic we are
00:46:51
kev and pandaops:We do also want to mention that 6s slots and focil tend to touch different parts of the system. This feature is not true if we ship focil/epbs/bals. There’s always overlap ofc, but focil and 6s are relatively separate features.
00:47:14
Ben Edgington:Fwiw, committing to headliners 2-3 forks out seems fine to me.
00:47:23
Trent:this group chose ePBS as a priority. There are complexity consequences to decisions, and we simply cannot do everything desirable in the same fork
00:47:44
Mehdi Aouadi:Replying to "FOCIL in H fork with..."
Not sure 6s slots and FOCIL are orthogonal since focil is time sensitive. IMO there will be some design/timing challenges to keep focil reliable. And yes, FOCIL will probably delay the fork (be it because of the testing complexity or the protocol design) but anyway, a 6 months fork is already not possible even with ePBS alone
00:47:45
Justin Florentine (Besu):Replying to "this group chose ePB..."
but most of the client teams just said they can
00:47:58
kev and pandaops:Replying to "this group chose ePB..."
I see it as a positive problem! We’re all so enthusiastic about improving etheruem 🙂 we just gotta temper expectations a bit sometimes.
00:48:20
Ben Edgington:Replying to "Fwiw, committing to ..."
Doing frequent upgrades de-risks this and increases certainty.
00:48:22
kev and pandaops:Replying to "this group chose ePB..."
@Justin Florentine (Besu) well depends on the timeline, if were fine with no fork in 2026 - sure
00:48:26
Potuz:Replying to "this group chose ePB..."
"They can" there's nuances to that
00:48:45
Justin Florentine (Besu):Replying to "this group chose ePB..."
and those nuances are being ignored in this conversation
00:49:02
Francesco:Replying to "this group chose ePB..."
There was a “we can do it all” moment circa May 2024 😆
00:49:03
kev and pandaops:Replying to "FOCIL in H fork with..."
The difference is that 6s slots is not a moving target, once we decide its 6s - there’s a design consideration that can be taken as truth
00:49:07
kev and pandaops:Replying to "FOCIL in H fork with..."
This is not true for most other EIPs
00:49:08
Potuz:Replying to "this group chose ePB..."
we definitely can, and my preference would be to commit to shipping it, but admitting that we don't care more about fork cadence than fork content
00:49:18
kev and pandaops:Replying to "FOCIL in H fork with..."
It would ofc be a problem if we didn’t know if we wanted 6s Or 4s or whatever
00:49:20
kev and pandaops:Replying to "FOCIL in H fork with..."
But that isn’t the case
00:49:29
Trent:Replying to "this group chose ePB..."
Testing and pandaOps are pointing out the complexity risk beyond timeline. Multiple client teams have pointed out the risk
00:49:46
Justin Florentine (Besu):Replying to "this group chose ePB..."
there is always risks, and some are acceptable
00:50:06
Potuz:Replying to "this group chose ePB..."
I think Pari is right re: testing ePBS+FOCIL, I think he's wrong re: testing 6s + FOCIL
00:50:07
kev and pandaops:Replying to "this group chose ePB..."
Well there risk is also that we ship none of the other glamsterdam benefits in 2026, is that risk worth it? - im not sure.
00:51:21
vitalik:I agree with "fast glam is good" from a decentralization/CR perspective
00:51:43
Potuz:Replying to "FOCIL in H fork with..."
@Mehdi Aouadi exactly, I think this is the main mistake pandaOps is making in their estimates
00:51:59
vitalik:because BAL + zkevm unlocks super efficient full nodes
00:52:04
Potuz:Replying to "FOCIL in H fork with..."
I very much contest the concept that testing with ePBS will be more complicated than with 6s
00:52:30
Potuz:Even if our commitments aren't "credible", why can't we at least make them?
00:53:03
Sophia Gold:Replying to "Even if our commit..."
i think we need to say what we will actually do, different from past commitments, to ensure this one happens
00:53:04
soispoke:I don’t think we have a credible way to commit to it, the best way to commit to it is to ship it in Glamsterdam
00:53:11
kev and pandaops:Replying to "FOCIL in H fork with..."
Our claim is based on the thought that epbs will still undergo changes (so far this has proven true). 6s slots mostly has fixed constraints that can be taken as true for FOCIL specs.
00:53:27
Potuz:Replying to "Even if our commitme..."
every single fork since I arrived to Ethereum we said "we will do Verkle next"
00:53:46
Justin Florentine (Besu):we can't do that thing again, where research vetoes client teams and then we promise to tweak the process to address in the future.
00:54:02
Trent:Context changes
Tech changes
00:54:17
Potuz:Replying to "Even if our commitme..."
the very same thing was said many times to Verkle
00:54:17
kingy_sigp:SFI FOCIL for heka sounds appropriate
00:54:17
kev and pandaops:Replying to "we can't do that thi..."
I mean the team pushing for focil is a research team itself...
00:54:18
nixo:i think we should take a week or two to think about how to credibly commit.
and also, CFI seems more appropriate than SFI to me
00:55:04
Francesco:Replying to "we can't do that thi..."
Not only that, but there are non-research teams pointing out the same things? Pandaops, testing, some client teams even
00:55:34
Francesco:Replying to "we can't do that thi..."
I don’t think it’s healthy to put everything in terms of research vs development or something like that
00:55:36
soispoke:Glam > SFI > CFI > softer commitment
00:56:08
NC:Replying to "i think we should ta…"
Epbs didn’t get cfi’ed and sfi’ed later on. It got sfi’ed right off the bat
00:56:10
Justin Florentine (Besu):Replying to "we can't do that thi..."
yes, the client teams are point out the complexity as well, and yet still think it should be included or are neutral on the matter
00:56:38
nixo:SFI is strong but it skips the point of CFI -> SFI for signalling purposes
00:56:42
soispoke:But people were involved for Glamsterdam already...
00:56:49
soispoke:And they clearly expressed support
00:56:57
Barnabé Monnot:Replying to "you’re muted potuz"
my bad
00:57:07
Sophia Gold:why not have the H headliner discussion now? we need to pipeline work on 6s slots too
00:57:10
nixo:agree with potuz - we skip the headliner process, which doesn’t feel fair to anyone who’s not at this call and expects the Heka headliner process to kick off later
00:57:18
Justin Florentine (Besu):it's kinda wild to just make up a new process feature on the fly. i think planning +2 is great, but we should actually plan out how that will work.
00:57:39
Trent:Replying to "why not have the H h..."
Lots to pack into a 90min call
00:57:41
Francesco:Replying to "we can't do that thi..."
Also just want to point out that the headliner of this fork is epbs 😄 Famously the favourite EIP of the research team
00:57:43
Dustin:Replying to "agree with potuz -..."
This is the first time the process has been used at all; it's subject to change
00:57:52
stokes:Replying to "it's kinda wild to j..."
Yeah I think we should take another call cycle
00:57:59
Potuz:Replying to "we can't do that thi..."
lol
00:58:02
stokes:Replying to "it's kinda wild to j..."
Agree we don’t need to yolo something right now
00:58:10
Barnabé Monnot:Replying to "agree with potuz - w..."
We should at least take a moment to discuss the best next steps here. But imo the discussion is going in the right direction, how do we allocate scarce client and testing resources well
00:58:12
Dustin:Replying to "agree with potuz -..."
It's intrinsically incompatible to ask for n+2, n+3, etc commitments, for example
00:58:51
Toni Wahrstätter:Tbf, the community is not ignored here. They were loudest about ePBS and they were heard.
00:59:02
Potuz:Replying to "it's kinda wild to j..."
Yes, this should be clear anyway
00:59:15
Potuz:Replying to "it's kinda wild to j..."
we can't make such a decision today, except include or not in Glamsterdam perhaps
00:59:17
Stefan Bratanov:We mentioned multiple times that we want faster forks, it would be a good practice to have a quick H* fork with FOCIL as a headliner
00:59:48
soispoke:Replying to "Tbf, the community i..."
I mean right now just speaking of client teams:
3 teams explicitly want to SFI it for Glam
2 teams expressed conditional support (as in support with caveats, mainly around fork complexity and timelines)
1 team would rather DFI it
00:59:54
NC:Replying to "We mentioned multipl…"
Are you suggesting no 6s slot in H star?
01:00:05
soispoke:Replying to "Tbf, the community i..."
How many times do we have to get feedback before we SFI something
01:00:11
kev and pandaops:Yeah agreed, FOCIL taken as a given main EIP for H star makes sense to us. Gives the credibility to the focil team, while still leaving scope open for a traditional headliner process for Hstar.
01:00:16
Potuz:Replying to "We mentioned multipl..."
That would be my headliner for H for sure
01:00:18
Barnabé Monnot:One thing that happens with DFI’ing FOCIL is we have much more space for doing some of the preliminary work on 6s slots that is analytics/testing heavy. Just much better use of pipelined resources imo
01:00:29
Enrico Del Fante (tbenr):Replying to "We mentioned multipl..."
Mine too!
01:00:32
Francesco:Replying to "We mentioned multipl..."
This doesn’t just depend on the CL to be fair, the EL independently has important things to do that will impact how H* is scheduled
01:00:44
Potuz:Replying to "We mentioned multipl..."
Sure
01:00:51
Justin Florentine (Besu):Replying to "Tbf, the community i..."
broader community was very supportive of focil for G* when we chose ePBS too.
01:01:01
Stefan Bratanov:Replying to "We mentioned multipl..."
Yes, 6s in I
01:01:05
soispoke:Replying to "Tbf, the community i..."
yes
01:01:48
kingy_sigp:if we're delaying focil we can reconsider 7688 and 8045 that seem to have support from other CL teams
01:01:53
Trent:The broader community does not have the same levels of context and does not bear the responsibility of testing and troubleshooting
And ultimately would not have the burden of dealing with mainnet issues should they arise
01:02:04
Caspar Schwarz-Schilling:Moving ahead with scoping other EIPs is tricky without having a decision on FOCIL?
01:02:22
Justin Florentine (Besu):Replying to "Tbf, the community i..."
right, the client teams do.
01:02:36
Trent:Replying to "Tbf, the community i..."
Client teams are bad at overcommitting
01:02:38
soispoke:Replying to "Tbf, the community i..."
And both the community and the client teams agree
01:02:40
Toni Wahrstätter:Replying to "Tbf, the community i..."
It's not only client teams that are busy with forks
01:02:48
NC:Replying to "Tbf, the community i…"
@Trent then this fact needs to be communicated well to the public and see if they change their mind
01:03:48
Trent:Replying to "Tbf, the community i..."
The community delegates stewardship responsibility to core devs who work on this stuff full time. in most cases, they necessarily do not have the capacity to make informed decisions
01:03:55
Toni Wahrstätter:Replying to "Tbf, the community i..."
I'm not against focil. I'm just not a fan of shipping a big fork, having seen how complex ePBS by itself is.
01:04:34
Potuz:I really think those EIPs won't change at all the landscape re:consolidations
01:04:49
Caspar Schwarz-Schilling:tldr: Drop 8068 in favor of a higher fee in 8062 (much better tradeoff re complexity/goal)
01:04:51
soispoke:Replying to "Tbf, the community i..."
@Trent so who is the voice of reason then if it’s neither the community or core devs
01:05:58
lightclient:Replying to "Tbf, the community i..."
Pandas?
01:06:10
lightclient:Replying to "Tbf, the community i..."
dont laugh
01:06:11
soispoke:Replying to "Tbf, the community i..."
Haha ok fair enough
01:06:21
NC:I feel like having a maintenance hard fork to adjust consolidation and make every mechanism in the protocol is used as intended would be nice
01:06:35
Trent:I should have been more specific
Core contributors broadly (not just “devs”), and client teams specifically overcommit
Tim and stokes tried to caution what happened in pectra. Pandas and testing are strongly cautioning against FOCIL in glam
01:07:02
Justin Florentine (Besu):Replying to "Tbf, the community i..."
"pandas" is at least a reasonable answer, but i'm not convinced they think it's impossible for G*
01:07:11
Caspar Schwarz-Schilling:Replying to "I really think those..."
The fee gives us a lever to lean into even more in the future. Say we start with fair fee (resource consumption wise) and it’s not sufficient, we can then decide to be more explicit and increase fee to very explicitly incentivize switching to 0x02 vals
01:07:16
Barnabé Monnot:Replying to "Tbf, the community i..."
Nothing is impossible, some things are unreasonable
01:07:40
kev and pandaops:Replying to "Tbf, the community i..."
We don’t think it’s impossible, we think it comes with the risk of no fork in 2026 + higher complexity. it’s definitely possible given time.
01:07:53
terence:what about centralized exchanges
01:08:01
Greg K | Lido:Replying to "Screenshot 2025-11..."
If the goal is to switch to 0x02, then just incentivize switching (8068), penalizing 0x01 does not seem fair.
It should be okay to have some validators of type 0x01 (by choice or necessity) don't see why they should pay a penalty for that
01:08:40
Francesco:They can just switch though
01:08:42
Justin Florentine (Besu):Replying to "Tbf, the community i..."
right, and THATs what we're not talking about, the prioritizing of fork cadence over fork content.
01:08:53
Francesco:If we provide incentives to consolidate, it’s not fair to 0x01 then
01:09:07
Potuz:Replying to "If we provide incent..."
yes I don't think we need to provde these incentives either
01:09:19
Francesco:That’s great to hear 🙂
01:09:52
Francesco:Replying to "That’s great to hear..."
This is not great to hear 😅
01:10:29
Toni Wahrstätter:Replying to "Tbf, the community i..."
Imo, even if we delay, we still risk piling up too much complexity with only a few ppl remaining deeply understanding the protocol.
01:10:36
Francesco:90% consolidation would still mean 100k+ validators just for the remaining 10%, so a small minority would be putting a huge burden on the network
01:11:32
NC:Replying to "Tbf, the community i…"
@Justin Florentine (Besu) definitely a fine balance between the two
01:11:42
Toni Wahrstätter:Replying to "Tbf, the community i..."
Like even if we delay until 2027, I'm not convinced it'll be an easy fork, just because it will still be big.
01:12:21
Justin Florentine (Besu):Replying to "Tbf, the community i..."
i thought ethereum was supposed to be more ambitious
01:12:42
Justin Florentine (Besu):Replying to "Tbf, the community i..."
(j/k i know ambition is just price coded)
01:12:46
Greg K | Lido:Replying to "If we provide ince..."
This is why I said "if we want to provide incentives, then ... ".
Btw effective balance definition in 8068 is much more reasonable than the current one anyways imho
01:12:50
terence:lol
01:13:10
kingy_sigp:I think we need another cycle if FOCIL is being delayed. That's a big change to what we had planned internally.
01:13:15
lightclient:It seems like too much contention to accept FOCIL?
01:13:20
kev and pandaops:Glad to play the classics of potuz and bbusa disagreeing
01:13:40
terence:Replying to "Glad to play the cla..."
need a polymarket for this next time
01:13:47
kev and pandaops:Replying to "Glad to play the cla..."
I miss the good old days (barnabas)
01:15:30
Francesco:Note about that is that if we really care about that issue we could also replace 71 with the churn sharing mechanic
01:15:34
Sophia Gold:if we're giving it another call, perhaps pandaops or others can come back with a proposal for structure of early work for both FOCIL and 6s slots to increase their likelihood of shipping on time
01:15:39
Francesco:Replying to "Note about that is t..."
(Without everything else that 61 does)
01:15:39
NC:Replying to "It seems like too mu…"
Because we don’t have a way to express credible commitment in H* that that crowd agree
01:16:18
Francesco:Replying to "Note about that is t..."
Agree with potuz that the preferable thing to do is the 61 mechanic, at least we make better use of the churn
01:16:28
terence:is there a consensus spec PR for 8061?
01:17:02
Potuz:yes that thing is the simplest change I can actually think about
01:17:15
Potuz:cause then it's strictly better than 8071
01:17:17
Justin Traglia:Replying to "is there a consensus..."
Not that I’m aware of .
01:18:24
Barnabé Monnot:Replying to "It seems like too mu..."
Not sure the credible commitment is a need-to-have to DFI focil. It is a nice-to-have for fork planning tho
01:19:57
kev and pandaops:If there is a mass slashing event on mainnet, it would be very good to have this.
01:20:01
Francesco:Replying to "yes that thing is th..."
Assuming this was about the churn sharing thing, I could discuss with Mikhail to replace 8071 with it if people feel that it’s a better solution for that problem in isolation
01:20:03
stokes:Replying to "If there is a mass s..."
That’s true
01:20:14
Francesco:Replying to "yes that thing is th..."
So we could more easily make that decision separately from the churn limit stuff
01:21:02
Caspar Schwarz-Schilling:Replying to "It seems like too mu..."
I think that ignores a lot of support for FOCIL. Credible commitment seems like a necessary condition for just DFI’ing FOCIL now, or need to go back to FOCIL conversation now.
01:21:12
Anders Elowsson:To state in the comments what I said on 8068 also: I just want to make sure people understand that the way to earn the highest yield on Ethereum is to just run multiple 32.75 ETH validators at 33 EB. If we believe it is going to be too complex for people to fiddle with this and not worth the energy, then we can ignore that concern as well.
And it may very well be too complex and we may not think people will do it. I think that could be a reasonable assumption. I just want it to have been understood and considered.
01:21:48
Caspar Schwarz-Schilling:Replying to "It seems like too mu..."
We moved on with conversation because credible commitment was brought up as a path out of the glamsterdam conundrum
01:22:30
Francesco:Seems like a good enough reason to at least not SFI and just look into it a bit more first
01:23:43
Francesco:Process q: if I were to move out the “churn sharing thing” into a separate EIP, would people complain that it wasn’t PFId on time?
01:24:05
Anders Elowsson:Replying to "Process q: if I were..."
It is grandfathered in 🙂
01:24:20
cayman:nice to have, opens the doors to use progressive ssz types for future features
01:24:23
kingy_sigp:Replying to "Process q: if I were..."
probably - people do be complaining. worth doing though.
01:25:09
NC:Stable container will be the new meme for the longest pfi’ed eip in ethereum history
01:25:14
Potuz:Replying to "Process q: if I were..."
@Francesco that nonexistent EIP is my favorite by far, and we can get into the deeper discussion of the rest of 8061 and the right 7d vs 10d vs 30d WS separately.
01:25:34
Potuz:Replying to "Process q: if I were..."
Aren't you the author of 8071? just change it :P
01:25:56
Potuz:Replying to "Process q: if I were..."
Or was it Misha, get him to change it, and then it was PFI
01:25:57
kingy_sigp:7688 and 8045 both were nice to haves for us. Without FOCIL we could more likely consider these in scope.
01:26:07
Greg K | Lido:Lido on 7688: https://github.com/ethereum/pm/issues/1754#issuecomment-3410880980
01:26:09
Lodestar Team:Replying to "Stable container wil..."
It’s the nicest thing to have every time, but never necessary enough
01:26:18
Francesco:Replying to "Process q: if I were..."
Mikhail and I
01:26:34
Potuz:@kasey said that it wont be too much for us to include it
01:26:36
Francesco:Replying to "Process q: if I were..."
Well I think from this call there’s people that prefer the other approach
01:26:44
Francesco:Replying to "Process q: if I were..."
So maybe it isn’t fair to just delete it from existence
01:27:25
Lodestar Team:Not a huge lift for Lodestar either for stable container
01:28:17
Anders Elowsson:Credible commitment..
TFI - targeted for inclusion?
01:28:44
soispoke:Replying to "Credible commitment...."
Please not one more acronym 🙂
01:29:01
Potuz:please do it
01:29:06
kingy_sigp:no issue
01:29:25
Lodestar Team:No issue here either
01:29:26
NC:Looks like the credible commitment discussion just suddenly stopped. What’s the outcome of that discussion?
01:29:30
Jihoon:Do we put all candidates on the table when discussing the headliner for H* or just FOCIL?
01:29:39
Anders Elowsson:Replying to "Credible commitment...."
Hehe
01:29:54
Sophia Gold:Replying to "Do we put all cand..."
i think for the CL we should
01:30:06
Sophia Gold:Replying to "Do we put all cand..."
why not? it seems obvious
01:30:11
Potuz:yeah, FOCIL happens to be both layers
01:30:31
Jihoon:Replying to "Do we put all candid..."
So.. it's a good way to delay FOCIL further with the same reason?
01:30:52
cayman:Replying to "Looks like the credi..."
sounded like "take convo offline, figure out process patch to support this"
01:31:01
Barnabé Monnot:❤️
01:31:10
kev and pandaops:Replying to "Do we put all candid..."
I think it’d be additive given that FOCIL is SFI-ed right? So the discussion would be for other headliners rather than a replacement headliner
01:31:31
Jihoon:Replying to "Do we put all candid..."
Is it SFI'd for H?
01:32:18
wolovim:Replying to "Do we put all candid..."
not on this call
Summary
8 highlights
· 1 decisions · 4 action itemsExperimental
Summary
8 highlights · 1 decisions · 4 action itemsExperimentalfork status and schedule
- Holesky BPO2 activated successfully 24 hours prior; mainnet in 3 weeks00:04:08
critical infrastructure
- BPO documentation process unclear - interfork meta-EIP vs fork-specific approach debated00:07:15
client updates
testing progress
- Target ePBS DevNet 0 by mid-December with Kurtosis-based interop testing00:13:21
organizational
- Client positions on FOCIL in Glamsterdam: Lighthouse/Lodestar/Teku support; Grandine oppose; Nimbus/Prysm conditional00:21:08
- Testing/pandaops warn FOCIL adds 3-6 months delay; ePBS+FOCIL share fork-choice/networking complexity00:34:07
- Vitalik: need to be willing to make multi-fork commitments and signal CR and decentralization priorities00:47:11
Action Items
- Client teams and pandaops: Target ePBS DevNet 0 by mid-December00:13:21
- stokes and community: Develop credible FOCIL commitment for H-fork; discuss next ACDC01:00:26
- Francesco: Split churn-sharing from EIP-8061 as alternative to 807101:14:14
- All client teams: Finalize all CL EIP CFI/DFI decisions on next ACDC01:27:17