stokes:Thank you. Okay. Hey, everyone.
Transcript
stokes:Welcome to ACDC, this is call number 171.
stokes:It is issue 1825 in the PM repo. There's the agenda in the chat.
stokes:And, yeah, I think it'll be…
stokes:Well, there's a lot on the agenda here, so yeah, let's go ahead and get into it. So…
stokes:First up, Fusaka. So, as we all know, we had Mainnet just recently.
stokes:And… went pretty well. There's at least one issue with PRISM. I think they're working on a post-mortem for that.
stokes:Yeah, and then this week we had BP01, which, again, seemed to have gone pretty well.
stokes:Would anyone like to add anything for either of those two events?
stokes:I know for the post-mortem, I think prison might still be working on it.
Barnabas:Yeah, so, BP01 looked very good. That was happening earlier this week. We did a quick,
Barnabas:blob spamming test as well, just yesterday. We were able to do 15, blob transactions in 28 consecutive slots, and the network, didn't seem to mind it at all, so that's good.
stokes:Okay, great.
James He:For Prism, I guess we've recently released, two new releases. One release that's just a hotfix, so that you don't need the flag anymore, and then, we had another release with,
James He:Semi-super node, feature and a backfill feature.
James He:There's still a couple other things we're still investigating, but,
James He:Just wanted to call that out.
stokes:Yeah, great. And that was, like, 701 for the patch, and then… Was there a 710?
James He:Yeah.
stokes:Okay.
stokes:Thanks.
stokes:Potus?
Potuz:Yeah, we've noticed something that, perhaps is affecting other clients as well. We, we had some users reporting, like, a bad degradation on attestation performance, and it boiled down to disk.
Potuz:We… we aren't, calling… attesting on a block until we saved all of the column sidecars.
Potuz:And it turns out that some nodes that had moved, database to slower disks
Potuz:are now… were performing perfectly fine before Fulu are now performing badly because of this. So, it might be a general thing, we are looking into how to optimize this, but, but yeah, so we're urging our users to move to NV, to faster disks, just because of this.
stokes:And you think it's because of the blobs, or something else?
Potuz:Well, I think it's just this thing of, like, attesting while we are storing. Just replying to Raul, it's… it's a dangerous, it's a trade-off. If you… if you fail storing, then you need to go back and do something about it, because otherwise you'll be on an async situation where your database is telling you that that block was available, but then you don't really have the columns that you need to adjust for.
Potuz:So I think it's… yeah, it's these kind of situations where you don't want to be a sink.
Raúl Kripalani:Yeah, remind me, did we have in a… do we signal the head slot, the latest slot that we have custody for, in the metadata message, or the status message?
Raúl Kripalani:Because if we do, then you could just not update that until it's written to disk. So you wouldn't be expressing that you have custody yet.
Potuz:Well, the problem is, what happens if you get the child? And then, you'd be syncing a block.
Potuz:For which you've said that the parent was available, and now you don't have the columns to even serve them.
Raúl Kripalani:Mmm.
Raúl Kripalani:Okay, I suggest we take this offline. There's a thread, I think, already in Discord, so we can continue there, and we can dig deeper. I do think there's some trade-off that we can, like, optimal trade-off that we can hit here.
Potuz:Yeah, we are… we are going to optimize this anyways, but just to flag this, that this.
Raúl Kripalani:Hmm.
Potuz:This is affecting users that don't have fast disks, and it wasn't before.
stokes:Okay, yeah, thanks for raising that, Enrico.
Enrico Del Fante (tbenr):Yeah, just, comment on that. So, I think, like, we… when we are… when you are test… you're testing that you have seen things, so the sampling was okay, so I think it's theoretically
Enrico Del Fante (tbenr):Okay to attest while you are storing, and then it's just a problem of guaranteeing… guarantee that you can serve that?
Enrico Del Fante (tbenr):So if you are…
Enrico Del Fante (tbenr):also serving via RPC, things that are in flight is okay, and then the problem is just having
Enrico Del Fante (tbenr):The database consistent when you start up the node, and making sure that you are filling, eventually, gaps that you are creating while stopping the node, and you haven't finished writing stuff on disk.
Enrico Del Fante (tbenr):that's a thing that we are dealing with.
Potuz:But even attesting is an issue, right? Because you have a separation of the validator client and the beacon node. So, by attesting, the validator client calls the beacon node, it says, what's your head?
Potuz:So to attest to that thing, the beacon node itself must have updated the block and said, this is my head. But then to do that, the beacon node itself must have declared the block available.
Potuz:And I think, being async here, saving your head, declaring locally on your Bitcoin node this block is available, but not having the column is… raises a dangerous… raises a danger.
Enrico Del Fante (tbenr):I'm not fully agree, but I think we can… can discuss.
stokes:Yeah, I think his point is that you do have the columns, they just went up, they persisted, right?
Enrico Del Fante (tbenr):I mean, it's attesting the availability, so if you've seen, it means that the data was available.
Potuz:Yeah, but the beacon node doesn't know it's seen something. It… so we… at least we consider things seen, like a block. Have I seen this block? Yes. If I have it in DB, I have seen it. I don't… I don't act on anything that I have not stored.
Potuz:Otherwise, I might end up in a situation in which my DB and my view of the chain is inconsistent, and this leads to bad bugs.
Enrico Del Fante (tbenr):But again, custody, to me, is different by sampling.
Enrico Del Fante (tbenr):So… That's the… that's the main point why I'm saying that it's okay.
Raúl Kripalani:Yeah, I think… I think that perhaps the difficulty here is that the status message, does not separate between the custody head and the chain head.
Raúl Kripalani:So, there's just a head slot.
Raúl Kripalani:So then, when you are externalizing that you have a particular slot that you consider head, any client would be entitled to ask you for the custody columns for that head. Which, in this case, you might not be able to serve if you haven't stored them in disk, and the client is not able to pick that… serve them from the buffer.
Raúl Kripalani:Which I think might be the solution here. Just, like, save them in the buffer.
Raúl Kripalani:But anyway, we can take it offline, because I think we're getting into implementation details now, but…
Raúl Kripalani:Yeah, I just wanted to say.
Dustin:I…
Dustin:I, I, I, I will say one, I agree, fine, take it off, find these are not implementation details.
Dustin:And I think that there's a lot of temptation to take these shortcuts that are not
Dustin:I mean, I… how do I say this? Without opening, you know, cans of worms here, but… which are dubiously valid, let's say. Debatably valid.
Dustin:It is not that easy.
stokes:Yeah, I mean, I think we might disagree on what's a shortcut and what's not. But yeah, Rol, you mentioned there was a thread somewhere in Discord, so…
stokes:Yeah, let's just move this somewhere else.
stokes:Okay.
stokes:Anything else on Fusaka? Otherwise, there's one more thing on the agenda.
stokes:But otherwise, yeah, then, you know, it may not be PO1.
stokes:Looks like they went well. This issue that we had just now… Anything else?
Enrico Del Fante (tbenr):Just…
stokes:Okay.
Enrico Del Fante (tbenr):One thing, yeah, we have, we have…
Enrico Del Fante (tbenr):Several, things that we will improve.
Enrico Del Fante (tbenr):You know, coming release.
Enrico Del Fante (tbenr):Some bugs here and there, so some… some of the clients using Tegu is… is not… is…
Enrico Del Fante (tbenr):Giving us some feedback, and we are improving.
Enrico Del Fante (tbenr):several things, so hopefully we will have something.
Enrico Del Fante (tbenr):by… this week on, Nishan, starting next week.
stokes:Okay, great. And this is around, like, new things in Fishaka with.
Enrico Del Fante (tbenr):Yeah, yeah, definitely. Stuff related to Fusaka, custody, and sinking, and so on.
stokes:Okay.
stokes:Great.
stokes:Thank you for the update.
stokes:Okay, then, the last thing here on the agenda for Fusaka is a bit of a bridge item, which is a retrospective process.
stokes:Let me grab the link really quickly.
stokes:Should be this one.
stokes:So…
stokes:Yeah, we did this starting with Pectra, and, you know, the context there was Pectra was, like, a pretty rocky fork.
stokes:So…
stokes:You know, we had the idea to do, essentially, a retrospective on, yeah, kind of the fork and the upgrade process generally.
stokes:Now that Fusaka is generally out the door, it makes sense to go ahead and do this again.
stokes:So, Nixon made this Ethan Magicians post here.
stokes:And the idea is for the next few weeks, just to have this open. Yeah, if anyone would like to provide feedback, this is a great place to do so. And yeah, this helps just refine how we do everything.
stokes:Yeah.
stokes:So, take a look.
stokes:And, essentially, the idea would be, this phase of the process would go until, we start ACD in the next… in the new year.
stokes:Which is, yeah, something like 3 weeks from now, so…
stokes:Take a look, you know, reflect, and…
stokes:And add your feedback there, when you have a minute.
stokes:Okay.
stokes:Anything else on Fusaka? Otherwise, we'll move forward into the future.
stokes:Okay.
stokes:So let's go…
stokes:And we had a few things here. So, one, there was this conversation about justice payments in EPVS,
stokes:We should talk about that.
stokes:Otherwise, the intent was to finish scoping for Amsterdam. We had a few open questions on some of the EIPs, that we'll get to.
stokes:In this section, so… To kick us off with trustless payments.
stokes:Let me just kind of replay, you know, at least my understanding of the frame here, so…
stokes:You know, we had this part of the EIP,
stokes:And it was selected in full as a headliner, you know.
stokes:A long time ago at this point.
stokes:We've had this conversation a couple times in ACDC of justice payments, and, you know, how the feature works, and, you know, should it be taken out, should it be split, different options here, should we leave it as is?
stokes:A few weeks ago, there was definitely some…
stokes:you know, input from the community here, in particular some of the existing builders and relays, and different people in the MEV ecosystem, who, you know, this would definitely impact.
stokes:They had some concerns around the design here.
stokes:So, they brought this to, I think it was 2 or 3 ACDCs ago,
stokes:In the meantime, we had a breakout.
stokes:Where, you know, I think we continued the conversation, and… yeah.
stokes:The point of all this, or at least, yeah, again, given the narrative, how we got to today, we should make a call on what to do with this.
stokes:So… yeah.
stokes:I'm happy to open the floor for comments. I can sort of play back my summary of where I think things are at.
stokes:Unless someone would like to add… their takes.
stokes:Okay. So, from what I've seen…
stokes:You know, what we had said, again, a few different calls ago, we basically would, you know, have trustless payments as is.
stokes:Unless there was some security issue.
stokes:And… yeah, again, I think this is…
stokes:Yeah, there are many different opinions here on what we should do. From what I've seen…
stokes:There have not been any arguments to the point that trustless payments are, like, actually negative or bad for the protocol?
stokes:There are some arguments that might suggest they're not being used, or, like, wouldn't be used, but then we have to take into account the fact of what we gain.
stokes:And what we gain is essentially this fallback for…
stokes:you know, what might be retail scenarios, but again, keeping in mind Ethereum's values and, like, what we're trying to do here in aggregate.
stokes:We can definitely make the argument that this is important, and that we should do it now.
stokes:So… I think that's essentially where we're at. We keep it as is.
stokes:in terms of what might start to be a compromise, you know, I think there's been some work around finding ways to…
stokes:allow the status quo of the MEV ecosystem to exist in this world. So at least that's something I would want to ask today, and or something I would, you know, want to keep working with the authors of EIP on.
stokes:is finding a way to make sure this is supported with, like, minimal disruption. Again, you know, I think in particular, having, relays be staked is… is an ask. I don't think it's a huge ask, and I think that's kind of the main difference. Otherwise.
stokes:You know, today's players can kind of live in the status quo.
stokes:So…
stokes:That's where I'm at. Again, I don't know if there are any other comments or perspectives we should raise.
alex (ultra sound):Maybe, like, just very shortly, wanted to speak some appreciation for everybody in… for engaging in the discussion.
alex (ultra sound):Maybe one very small meta point?
alex (ultra sound):just… that I've noticed, because I've spoken to a lot of people now about this, and I've noticed that on, regardless of what people's positions or opinions were, they…
alex (ultra sound):We're sometimes pretty worn out by the discussion.
alex (ultra sound):I think sometimes when you work on a really hard problem, that makes a lot of sense, right? Stuff is just hard, rest, support each other, and continue. But I feel like when it's… the resistance is more, like, people against each other, than maybe in general for the EIP process or future changes.
alex (ultra sound):I could imagine, this is very much my personal opinion, that slowing down might be very healthy to, right, work through some of these things, but again, I'll immediately say that I feel like a lot of people have really done their best to try and do precisely, that.
alex (ultra sound):So, thank you.
stokes:Yeah, thank you. Yeah, you definitely have been helping coordinate, you know, this investigation that
stokes:we've just had, which, again, I'm… I mean that in, like, a very positive light. We are going to get to the best divine by having the most people look at this and poke, you know, from every possible angle and corner, so…
stokes:Yeah, thank you for that.
stokes:And… okay, so… Again, I think then where we're at, we keep the EAP as is.
stokes:there's, I think, some questions around, you know, from here, details around how these different components should fit together, and again, I think we should…
stokes:Make sure that there's a way, again, that, you know, the current ecosystem will not be completely disrupted.
stokes:My understanding is that this is already the case. But yeah, let's just make sure that we can kind of…
stokes:Keep that in mind as we move forward with the design.
stokes:So… Any final comments on this?
stokes:I would say for the record, like, yeah, this is, I think, at least the second time we've kind of formally considered this.
stokes:And again, the takeaway is we're keeping them in.
stokes:I do feel at this point, we've done the work to hear as many people out as we can.
stokes:And… yeah, again, the only, you know, consideration, or the only point at which we'd want to revisit this is if there were, like, very, very clear security issues, which, again, no one seems to be able to find, so…
stokes:Any closing comments on that?
stokes:Before we go to the next topic.
stokes:Okay.
stokes:I don't know, there's some comments in the chat, but I think people should speak up if they want.
stokes:Yeah, Oscar.
Ansgar Dietrichs:Yeah, not at all to disagree with that decision. I think that's actually my decision, but, just maybe as a general comment, I do think
Ansgar Dietrichs:for many reasons, some of them definitely, I think, also triggered by some kind of behavior from the EF research side, but I do think, looking back at the history of the EFP and the governance process around it and whatnot, I feel like it relatively early on turned unnecessarily adversarial, and I think
Ansgar Dietrichs:it turned very much into a my proposal, your proposal kind of situation. I think there were several kind of, like, smaller adjustment ideas that then ended up never being really considered, given that it was like, oh, this is yet another attempt to basically subvert
Ansgar Dietrichs:like, one side winning or something, I don't know. Maybe this is purely my perspective, this could be, and then… my apologies for bringing this up. I just do feel like, once we have a retrospective, maybe for
Ansgar Dietrichs:the EPBS inclusion process, I do think we could have done more as a group. Again, not even, I think, in chat, I actually worded it a bit as inclusive as the champions, that was probably immature, I think more as a group as a whole, including from our side.
Ansgar Dietrichs:I think we could have done more to keep it focused on the technical questions, and I think there could have been more collaboration on, yes, let's move forward with EPBS, but also early on into the process, let's take some more time actually
Ansgar Dietrichs:working on potential iterations. So I do think there was something that didn't went well. I understand why the community now reacted the way
Ansgar Dietrichs:They did, but by now, I think we have a good headliner, maybe not perfect, but yeah.
stokes:Thank you.
stokes:There's a good question here.
stokes:from Francesco, I think we should address. So, yeah, again, I think, in part, to try to find, like, a nice middle ground between, again, kind of the status quo and what this EIP would introduce.
stokes:There are some proposals to modify parts of trustless payments, and I do think we should sort out, yeah, how we're going to resolve those.
stokes:You know, I think my sort of straw man would be what Justin's saying here in the chat, like, something like mid of January, we should say, like, pencils up on spec changes.
stokes:Potu's here. You said these are big changes. I don't know if you want to speak more to that.
Potuz:Oh, they aren't so big in principle, but they… so I guess the biggest concern here is that, for historical reasons, perhaps, this goes back to, like, 2 years ago, and discussions with Mike Neuter, actually, and the builders at that time.
Potuz:mentioned that, yes, they would… if they are going to be state, they would rather not be losing capital and then be earning rewards. But it turns out that now, when they are faced with the churn and deposit churn, they, they…
Potuz:said that they are… they seem to be aligned that they would rather forfeit the rewards, not be validators, keep the stake without getting rewards.
Potuz:And, and yes, and just take… take that as the… as the… Payment for bids.
Potuz:The problem of doing this, like, removing the builders from the validator slides, is that it also removes the ability for validators to submit bids. I'm not sure if this is a trade-off that we're willing to make, because this was the feature that allowed us to remove the self-building property.
Potuz:We were hoping that this set of validators would still be decentralized enough, that we can just remove the self-building requirement. Anyways, there's a bunch of discussion to do about this.
Potuz:I believe that we can actually implement these changes. I think this is an honest request from builders to avoid the churn.
stokes:Right, and so to be clear, this is taking away the validator duties of the Xerox3 validators?
Potuz:Right, so it would be taking away the validator duties, and in this way, we can allow them to deposit faster. They still would need to go over a long term to withdraw, otherwise this is a DOS.
Potuz:But it will allow them to deposit and get included quickly, because it wouldn't even affect a week's substitutivity period or anything. So it's easier… it makes the protocol easier to reason about. There's many reasons why you would want to have something like this. You could also, in principle, include builders that are only staked for one ETH, or minimally.
Potuz:And then they would be able to bid for this match.
Potuz:But, yeah, so, I think for me, the biggest loss of such a system would be the fact that we lose this very nice feature, which is validators are able to submit bids.
stokes:Okay.
stokes:So, I think in terms of moving forward, you know, I think getting clarity here.
stokes:Base up, is what we should do.
stokes:Yeah, I assume there are still EPBS breakouts. Like, I think this is something we should be covering on the breakouts until we get to some resolution.
stokes:Yeah.
stokes:Like, I think it's a little premature to be like, okay, you know, by January 15th, like, pencil's up.
stokes:But if anything, that's, like, a target I think we should keep in mind, and sort this out as soon as possible.
stokes:You know, one way to de-risk this moving forward is just…
stokes:Yeah, I mean, again, we have history here, but if we can get to a place where we do the more permissive thing first.
stokes:To add, you know, essentially more restrictive things later, we should do that.
stokes:Oh, let me rephrase that one.
stokes:What I mean is, like, you know, if we can do something such that it's, like, more future… like, more forward compatible later, we should do that.
stokes:In the event that, say, we want to ship and, like, do these iterations down the line.
stokes:Okay. Yeah, Francesco's saying here in chat that he's worried we might not be able to sort this out.
stokes:Yeah.
stokes:I think it's worth at least, yeah, taking another breakout call to really investigate this in earnest. It sounds like we have an idea. Like, is it really just this one idea?
stokes:Of having non-validating stick builders.
stokes:Okay, I mean, that sounds like it… what… it sounds like the situation to me, so…
stokes:Let's keep moving forward on that. This should be the topic of the next breakout, and yeah, let's try to assess there how this looks like in terms of, yeah, any additional changes, and what that means for… what that might mean for…
stokes:I'm meaning things.
stokes:Okay.
stokes:Any other comments on trustless payments for the moment?
stokes:Okay.
stokes:So… That's that. And… okay, next up, would be doing the non-headliner EIP scoping.
stokes:So… okay.
stokes:We have a number of VIPs to touch on to round out the Glamster Dam scope.
stokes:One of them is the question of fossil that we had. There were questions then around 7688.
stokes:8061 and 8080.
stokes:And I think those were the last ones on the CL side that we needed to get through.
stokes:So… Let's go ahead and touch on Fossil.
stokes:So… yeah, again, this is also, you know, I think there's been some history here with this EIP.
stokes:What we had said, you know, the process for this.
stokes:was that, you know, there were concerns around Scoping and Glamsterdam, And…
stokes:And because of that, you know, we wanted to think about putting it into a feature fork, say HECA,
stokes:As part of that, you know, it'd be nice to have some credible way to commit to HECA, or commit to Fossil and HECA.
stokes:And I feel like we tried this on the last call.
stokes:I think there was already confusion.
stokes:around, you know, should we do CFI, should we do SFI, and how that should work?
stokes:So, that all being said, you know, as of the last ACDC, the points were made, you know, hey, we essentially shouldn't get just, like, you know, different client team members' opinions just in time.
stokes:we should also reach out to the execution layer. So yeah, so we took this to ACDE last week.
stokes:And I think, again, people are generally supportive of including this in some fashion.
stokes:And I think that essentially brings us to today.
stokes:So, you know, I think following that arc, you know, I'm willing to have a conversation if people want to try to think about scheduling
stokes:Fossil in some form or fashion, ECA.
stokes:But… I will also say at the same time, having thought about this some more, I think…
stokes:What will happen is it will be tricky to say, hey, you know, we should ignore the process.
stokes:Process being just opening up the headliners, for HECA and moving forward that way.
stokes:So, you know, if people want to…
stokes:Essentially, yeah, raise points for one way or the other, you know, we should do that now.
stokes:I do think right now my recommendation is just to say, hey, you know, we tried this, it's going to be hard to get consensus, I think especially given the fact that
stokes:If we do want to deviate from the process, it should be, I think, fairly uniform that this is what we want to do.
stokes:I think already some people have called out that we should not ignore the process that we have laid out with headliner selection, etc.
stokes:So that would mean going to the headliner process for HECA, with this question of fossil.
stokes:one quick side note, and then I'll stop talking. Given that we just finished up Fusaka, this is… essentially, now is the time to think about headliners.
stokes:for ECA, which I'm gonna touch on this after we finish this EIP scoping for Amsterdam.
stokes:But, yeah. Point being, we would start the headliner selection process for HECA, essentially, you know, start of next year, so in just a few weeks.
stokes:Okay.
stokes:Yeah.
stokes:So I spoke.
soispoke:Yeah, thanks, that was, yeah, I think that was a good recap. I mean, my opinion is that we should…
soispoke:It would be quite healthy to stop, like, moving the goalpost, and…
soispoke:And we keep asking clients what they think, and they keep basically saying that they are in favor of included, but then we keep moving anyways. And I also just want to add that
soispoke:We are, again, like, in a situation in which most of the pushback on Forsole is about process. It was already the case for Glamsterdam, and now we are basically repeating the exact same pattern for H-star.
soispoke:I actually think it maybe echoes… well, I don't want to take his word, but, like, what Anzaga was saying was, like, decisions being made on technical merits of an EAP of a feature, rather than just, like.
soispoke:Focusing on, on the process, and…
soispoke:Yeah, I feel like, at some point, like, if, you know, if people have, like, strong technical reasons to be concerned, but also, or they actually don't support it, like, they should voice it, but it's not been the case for a while, and I do think there is, like, a sort of limit
soispoke:To allowing… allow… allowing, sort of, like, veto power if the pushback from,
soispoke:people that don't want to see fossil in is just about process.
soispoke:Yeah, the last point is, you know, I think I said that on ACD a bit, but…
soispoke:continuously having, client teams sort of, like, have to come up with opinions, about an IP.
soispoke:That means they need to have the actual discussions, they need to come together, come back with an opinion over and over again, and I think, like, it's quite wasteful in terms of time if we actually don't end up considering these opinions, so I just want…
soispoke:Maybe people to be mindful of.
soispoke:Yeah, draining this process,
soispoke:longer, which is why I would favor, like, actually coming to a decision, around fossil inclusion, just because it's been very long, and yeah, I will stop talking now.
stokes:Yeah, thanks.
stokes:Okay, yeah, Tano, and then maybe I can respond to Tama.
donnoh | L2BEAT:Yeah, so… I've been asked to express my opinion on the topic, so I spent a lot of time,
donnoh | L2BEAT:like, talking with L2s, because, you know, that's what I do at AltoBeat.
donnoh | L2BEAT:And Osil came out, a few times as a way to reduce the challenge period, which is something that, a lot of protocols want.
donnoh | L2BEAT:But, you know, even apart from this.
donnoh | L2BEAT:The two things I want to say is…
donnoh | L2BEAT:One of the reasons I think the conversation around fossil has been frustrating a little bit,
donnoh | L2BEAT:both people, you know, pro-folsale or against fossil is because I don't think we're, we're…
donnoh | L2BEAT:Like, discussing it, the proper way.
donnoh | L2BEAT:And I think the proper way to discuss fossil is to think about timely inclusion, right? So, first of all, we need to agree that timely inclusion is valuable.
donnoh | L2BEAT:And what I want to convince you is that it is. Like, there is a huge class of protocols that requires time and inclusion for safety. One obvious example is, you know, optimistic roll-ups with a challenge period.
donnoh | L2BEAT:Another example is the intent protocols, that also have a challenge period for settlement.
donnoh | L2BEAT:Another example is, stuff like polymarkets. They use a 2-hour strange period to settle disputes.
donnoh | L2BEAT:Or in general, you know, upgrade delays, exit windows, you want to exit, withdraw from protocol, you need time inclusion for safety, right? But it's not just about row censorship resistance, it's also about safety of funds.
donnoh | L2BEAT:And the proper way to model inclusion is through economic attacks. I've seen very, very few attempts to discuss fossil in the lens of
donnoh | L2BEAT:What is the advantage that it gives?
donnoh | L2BEAT:to a user, if there are, an economic attack, right? So I pay a tip to close the transaction, someone else pays another tip to, right, to push out my transactions.
donnoh | L2BEAT:There is only one paper, by Offshore Labs trying to discuss these benefits of fossil.
donnoh | L2BEAT:The outcome of this paper and the result is, it seems like it gives you, one other magnitude improvement, in the sense of, if you have an attacker that has $100 billion and wants to censor you,
donnoh | L2BEAT:in… without fossil, you need 10 times more money to try to include these transactions with fossil. I don't think the model is perfect, I think the model, needs to be improved.
donnoh | L2BEAT:It doesn't correctly matter faucet, in my opinion, but I think this should be how the conversation would need to go forward, and that's also why I think it's valuable to have a little bit more time to discuss.
donnoh | L2BEAT:the benefits of postal.
stokes:Okay, thanks.
stokes:Yeah, again, just sharing my perspective, given that I talked to many of the people on this call. I don't think anyone's really debating, at least to first order, like, the technical merits of fossil. I think it, you know.
stokes:In terms of how…
stokes:We got to today, it's really just a question of, like, when to scope it and, you know, what process gets us there.
stokes:And yeah, so again, you know, it was considered for Amsterdam. I think there are legitimate concerns around scope and complexity to not do that. Then the question was, you know, can we put it into the next work, especially given…
stokes:And I think what's pretty uniform support for it.
stokes:And then, circling back to… so I spoke, yeah, like, I agree the process has not been ideal, you know, it's been pretty rocky, and, you know, I think my answer to that today is just to say, hey.
stokes:Let's take a step back, lean back on the process, because that's something we can all agree to. That's just, like, sort of a, you know.
stokes:Established precedent that we have.
stokes:And…
stokes:then that would be my suggestion, is say okay. Given especially that we're starting HECA headlining just in a few weeks, this is the time to do that.
stokes:Carl.
Carl Beekhuizen:Yeah, I think my thing here is that it's like…
Carl Beekhuizen:Fossil does bring many amazing benefits that I think most people here would like to see. The reason I think it's important that we still go through the process is just that we need to consider
Carl Beekhuizen:Shipping fossil means we don't ship other things, we need to consider what are those other things, and whether
Carl Beekhuizen:we want to make those trade-offs in H-star, and I don't think those discussions have been had.
Carl Beekhuizen:So, for that reason, I think it's very important we go through the headliner process. I think it's very likely that we end up back at Fossil, and…
Carl Beekhuizen:Great then, but I think it's important to do that.
stokes:Yeah, and, you know, maybe to add to that, not just for us, but also to give the community an opportunity to weigh in.
stokes:And… Yeah.
stokes:There's some side chat, I don't know if anyone would like to speak up.
stokes:To add an input to the conversation.
nixo:I think… I think CFI-ing is, pretty uncontroversial at this stage, as, like, a…
nixo:as a positive signal, SFI is… is controversial, and I think that for that reason, we should go for CFI, because if we make it SFI, there's not really any meaning in the difference between CFI and SFI. I…
nixo:SFI's something as a head… as the first thing that goes in
nixo:Essentially denotes it as the headliner.
nixo:And so I understand the desire to move it to SFI as soon as possible to
nixo:make it the frontrunner, but it… it really should go through the process, and this, sFI-ing it to begin with makes this meaningless.
stokes:Oscar.
Ansgar Dietrichs:Yeah, while I tend to agree with Nixu, I personally also preferred to just have it,
Ansgar Dietrichs:steep aside, just given that I think Tomar had a point that we keep always asking, like, on all codefs, there's always the conversation, okay, what does… what do the codevs think? And then the codevs seem to have preferred, in the past, SFI, so I just wanted to say, if we go ahead with SFI, I personally would prefer the
Ansgar Dietrichs:The version of that where we just say, it is SFI already.
Ansgar Dietrichs:But we just go through the normal headliner process as usual, and in that headliner process, we will just consider, okay, we already have SMI for us, so does that mean we want to have it as the headliner? We could still decide to not have it as the headliner. I mean, as of one call ago, we were still
Ansgar Dietrichs:considering including it into Amsterdam as a non-headliner, so there's definitely precedent for it to potentially be a non-headliner. So we could just decide that as part of the headliner process. I don't think it would be too much of a bending of the process, and I would… if there's strong demand to do SFI already today.
Ansgar Dietrichs:I personally would prefer that over locking it in as a headliner, because that really, in a way, I think, is… is a bit of a violation of the headliner process.
stokes:Yeah, I mean, I think the catch there is, like, this should be considered a headliner. Like, you know, fossil is big, putting it into the program.
stokes:protocol will produce headlines, which is, like, you know, the intuition behind the name Headliner.
stokes:I think it was… so I spoke, and then Carl.
soispoke:Yeah, just wanted to say, I… I… I think the SFI is more important than the headliner for Fossil, because, again, I think…
soispoke:if we followed through the whole history, was about, like, trying to get a credible commitment for… for Fossil, whether it's a headliner or not. And… yeah, I mean, my worry right now is that
soispoke:you know, as a headliner, I already said that, but, like, forceful is very ill-suited, just because it is cross-layer, and it is quite a big EIP, but, like, it's not huge, and it's very ready, so it sits in between this sort of, like, EL and CL, and, like, huge
soispoke:Feature versus very small, which makes it, yeah, a bit…
soispoke:a bit weird, to fit in the headliner process, so I… I mean, I would be completely fine, SFI-ing it as a non-headliner, rather than CFI-ing it as a headliner, which I think is, yeah, more weird for the process.
stokes:Yeah.
stokes:I don't know, to me, like, Headliner is different than CFI or SFI, like…
stokes:headliner is an intrinsic thing around the importance and impact of an EIP.
stokes:And then, yeah, like, the CFI-SFI thing is kind of separate to that, where it's like, okay, we would have a headliner, and posted to that is that it's something that would be scheduled.
stokes:And then we move forward to the usual process where, okay, you know, we CFI something to say, again, it's being considered for inclusion. As soon as we are ready to put it onto DevNets and the R&D process, it becomes SFI.
stokes:And, you know, I think sort of the only shortcut there with the headliners is that they sort of de facto and or immediately go from
stokes:Let's see if I'd ask if I stop.
stokes:Carl.
Carl Beekhuizen:Maybe this is just a misconception on my part, but…
Carl Beekhuizen:My understanding of Headliner is also a lot to do with the size of this, and I do feel like the fossil's pretty big.
Carl Beekhuizen:I feel like it's wrong to be deciding.
Carl Beekhuizen:on whether you're SFI- this or not, based, like, without it… being…
Carl Beekhuizen:A headliner, because from my perspective, this is a rather large change.
Carl Beekhuizen:Maybe it's not as large as some of the other things we've had as headliners, but…
Carl Beekhuizen:So, pretty impactful.
Carl Beekhuizen:I think that's one thing. The second thing is, like, if…
Carl Beekhuizen:we are going… like, wanting to go down this route. In the past, we've first decided the headliners, and later on, decided what else goes in the fork, based on how much capacity we have left after deciding the headliners.
Carl Beekhuizen:They're the most important things, so I think specifying this before we do that, and then…
Carl Beekhuizen:Finally, I think the…
Carl Beekhuizen:credible commitment thing here is, like, something that's been run with a little bit too hard, and I think…
Carl Beekhuizen:There's a little bit of… we tried to abuse the process to try and make…
Carl Beekhuizen:this feature not go… not happen in Glamsterdam due to complexity, when I think that was a backwards way of doing this. I think this was… would have been too complicated to put in Glamsterdam, especially if you want to keep shipping things on shorter timelines.
Carl Beekhuizen:And so we should have just put the bulletin and been like, this can't be in Amsterdam based on that, we don't…
Carl Beekhuizen:need to.
Carl Beekhuizen:make these credible commitments, and I think, like.
Carl Beekhuizen:That was… I don't know if that was the initial intention, of these…
Carl Beekhuizen:things around credible commitments, but I feel like this spiraled very quickly out of control, and then people, like, feel let down because…
Carl Beekhuizen:They feel like we need to give them these things, around… Or on fossil.
Carl Beekhuizen:I just think there's, like, that the path of how we got here has been a little bit unfortunate, and has, like, resulted in a lot of this fatigue, and keep having to ask the dads what they want or whatever, and I think, as we mentioned, it's clear the devs do want something like Fossil, but
Carl Beekhuizen:It still needs to be considered within the greater picture, and…
stokes:Gonna talk?
vitalik:Yeah, I mean, I, yeah, like, I remember being in the call a couple of weeks ago, right? And,
vitalik:It certainly felt to me like, we were… we justified Fossil not being in Glamsterdam under the, arguments that, like, basically everyone wants it, and, it's, like, of course it's going to happen in H-star, and, the people saying that it'll just keep on getting pushed back more and more are being, like, unrealistic.
vitalik:and, like, from…
vitalik:that perspective, like, we definitely do have a history of pushing things back more and more, and, I,
vitalik:I think in this situation, there's a lot of, a lot of value in, like, actually, yeah.
vitalik:showing that we are able to, like, hold ticket… to commitments if we decide… if we decide to do them. And, I think, I mean, more…
vitalik:more generally, right? Like, the process needs, some kind of defense against, like, things, continually getting put… getting pushed back more and more until they, until they eventually don't happen, and just,
vitalik:like, basically the, yeah, like, actually, yeah, actually getting it out there and giving people confidence, that it will get out… that it will get out there seems like something that, a lot of people have been counting on. Like, I don't think we can…
vitalik:Isolated from all of the, all of the other discussions.
stokes:Right, yeah.
stokes:I think my take here is that it's definitely a headliner. Like, I think, you know, possibly is big, and it does have a lot of impact. We should be…
stokes:proud of that, and, like, give it the recognition it deserves, that it is a headliner. If it is a headliner, you know, we have this fairly new process around that, which would make it a bit tricky to…
stokes:move ahead with some, you know, definitely SFI today.
stokes:Again, because we are going to start the headliner process for HECA in, you know, just a few weeks' time.
stokes:So, I think given that we don't want to…
stokes:not respect this new process that we are trying to install to make ACD more smooth around scoping and EIP selection.
stokes:We should just respect that and move forward with this again in a few weeks' time.
stokes:I think it was June, then Carl, then my client.
Jihoon:I wanted to talk about
Jihoon:Also, but if the decisions already made.
stokes:Oh, sorry?
stokes:No, yeah, you can, yeah, you can, you can share.
Jihoon:Yeah, so, I just wanted to say… share that,
Jihoon:From my understanding, the main reason behind pulling fossil from Klamsterdam was fork scope, which affects some fork cadence.
Jihoon:And I do agree that we will also want to respect the process, but in terms of better pipelining perspective.
Jihoon:Sfi… I think SFI and Fossil will help us a lot to achieve faster fork cadence, as we can have developers' attention, either it be core devs or
Jihoon:APM Fellows, so… Regarding fossil readiness, we had 4 CLs and 1 EL interrupt a while ago.
Jihoon:Nethermind was close to make the intro, but has been busy with other stuff, and then EPA Fellows came up in a bottom-up fashion, and they've built RES and Aragon EL prototypes.
Jihoon:So, as soon as we can have core devs attention by SFI, for example, I expect we can have 8 clients interop very soon, which is more than enough for kicking off the first DevNet.
Jihoon:And yes, this is based on Fusaka, but we already know how to rebaste fossil onto Goloas.
Jihoon:And core devs have estimated development time for the rebase will be roughly a month, once we have working EPS implementation.
stokes:Yeah.
stokes:if anything, I think my takeaway from that is that, yeah, there's a lot of work that's gone into this, and so it should be a very straightforward, or let me say, it's a very strong case to be made for it as a headliner.
stokes:Okay.
stokes:You know, if we wanted to find some solution that still signals, like, hey, this is, very important and top of queue for core development generally, I think Nick's suggestion of CFI.
stokes:Today, makes a lot of sense.
stokes:But yeah, Carl and Matt, and then, yeah, we should probably move on to other things.
Carl Beekhuizen:Yeah, I want to push back against Vitalik a little bit, saying that we're, like.
Carl Beekhuizen:We have a history of delaying things.
Carl Beekhuizen:And…
Carl Beekhuizen:in order to, like, making sure that that was also not being shipped. I don't think that's the case here. I don't think anyone talking about
Carl Beekhuizen:This process here is, like, trying to delay fossil for the sake of not getting included.
Carl Beekhuizen:I think it's, like…
Carl Beekhuizen:Like, at least that's my perception. I know there's some people who really don't like fossil that much, but I don't think there are that many.
Carl Beekhuizen:I think it's more just about
Carl Beekhuizen:questioning whether it's the right thing to do right now, and I think the same has been true for many of the other things we've delayed. It hasn't been about…
Carl Beekhuizen:not wanting them at all. It's just been about, hey, we only have limited resources that we can spend on this, and is it the right thing to be doing right now? Is it the most impactful thing?
vitalik:Right, well, hold on, there's two separate arguments, right? One, which is that following the process is good, and the other is the idea that this is a lower priority than 6-second slots, and I think the second one is, like, one that, a lot of people are really against. I mean…
vitalik:I… yeah.
vitalik:I don't know, like, I feel really against it, because, they basically, it's, it feels like the sort of thing where, like, we, really would be just continuing to push, back everything related to censorship resistance more and more.
vitalik:And,
vitalik:Like, that, like… and so I think, like, it is, it is important to separate those two arguments now, right? Because, like, I personally talk to a lot of people who are afraid that, Ethereum is, going into a, kind of… basically,
vitalik:a mode that deprioritizes everything other than acceleration, and it's, like, really important to clearly show that, that's not what we're doing. And, that, like.
vitalik:Basically, the fossil is being eaten, delayed or done in a particular time for good technical reasons.
Carl Beekhuizen:I mean, I agree with what you said, I'm personally one of the people who thinks acceptance slots would be more impactful, but do you still really want to see Fossil on Chain at some point?
Carl Beekhuizen:I think from the people I've spoken to, I've seen a lot of the opposite opinion. I think
Carl Beekhuizen:a lot of people hear Fossil and think it's just a censorship resistance thing, and then don't understand that there's some nuances there, like…
Carl Beekhuizen:Fossil doesn't, include…
Carl Beekhuizen:censorship resistance for blobs, or fossil has this 8KB limit, so it's not really useful for people that use a lot of data, so it's not useful for the stock people. Things like that, I think, are…
Carl Beekhuizen:A little underappreciated and under-discussed.
Carl Beekhuizen:But yeah, I mean, that's the one…
Carl Beekhuizen:I do hear your points. The second thing I wanted to touch on quickly is just about…
Carl Beekhuizen:What we're talking about here in terms of timelines is, like, we're… the proposal's just to be discussing this again in
Carl Beekhuizen:January, where we're gonna have the headliner process.
Carl Beekhuizen:I don't… there's not like there's this major delay in terms of when we are discussing it, and I don't really see opinions shifting that much between now and then, so I don't think there's, like, this huge risk being taken by
Carl Beekhuizen:Hustle to be following the process?
Carl Beekhuizen:Anyway, I think my opinions are not on this one.
stokes:Alright, like Client, and then we'll wrap up.
lightclient:Yeah, I just wanted to say, I feel like we're trying to do some process engineering here. Like, it doesn't really feel like the right place to…
lightclient:talk about alternative proposals to fossil, or we're not really talking about technical aspects of fossil, we're just trying to close the fork scoping for Glamsterdam, and then we have this weird aspect of making a commitment for the future, and…
lightclient:It doesn't seem like an open process when we're, like, committing to the next thing, when we've already communicated what the process should be, and so people who might not agree with what the next thing is
lightclient:is supposed to be are not coming onto this call and, like, making alternative proposals. So I think, like Carl said, we're not saying we're never gonna do this, we're just saying, let's follow the process starting
lightclient:when the process starts as soon as possible, which is gonna be January, that's a month away. If it is the most supported thing for the headliner process, then we're just gonna put it into
lightclient:H-star, regardless.
lightclient:So, I think that CFI is the right thing to do there.
stokes:Caspar?
stokes:Most common.
Caspar Schwarz-Schilling:I just wanted to say that.
Caspar Schwarz-Schilling:The process, in my mind, as of last ACDC was to ask clients whether to SFI or not on this call.
Caspar Schwarz-Schilling:And I think clients can take into consideration whether they think it's too much of a deviation from the process.
Caspar Schwarz-Schilling:to SFI now, and decline it on the basis of that, but I think we've asked clients
Caspar Schwarz-Schilling:To form an opinion, and you can just ask them.
lightclient:The point of the process, though, is to communicate publicly about how we make decisions and do operations, and if the clients can always just, you know, pick what they want to do immediately, and not
lightclient:You know, have an open communication and process about it, then…
lightclient:You know, what was the point of even saying, this is how we're gonna do things?
soispoke:No, but it's been open and communicated.
lightclient:It's been open for Glamsterdam.
soispoke:Well, 5 months.
lightclient:It's not been… it's been open for Glamsterdam. It's not been open for H-star.
soispoke:I mean, we've literally asked clients again, right? Like, what do you guys think? And they…
lightclient:Again, it's not.
soispoke:Just for clients.
lightclient:It's for the entire community. It's for… it's an open process for everyone involved. It's not just, like, clients who are deep in this thing, who are coming to all the calls to come and say, you know, I want to do this next.
soispoke:What I'm saying is, last time you said, maybe we are afraid it's too… it's just, like, individual decisions, and basically emoji-based inclusion of things, so… and I think the decision was to say, okay, let's actually ask client teams once again, because that's fair, like, we actually need
soispoke:To ask them their opinions maybe one more time, and now we are doing that, and we don't…
soispoke:care, apparently, because we are asking them, but we don't take into account that… those opinions. So why are we asking them if we just move on anyways?
lightclient:I don't know, I wasn't the one who proposed we ask them. I think, and I've said from the beginning, that we should just do the headliner process ASAP and pick Fossil, or whatever, as the headliner.
lightclient:Not these, like, credible commitments that, like, circumvent the process.
soispoke:But then we are, like, in a very tough situation, right? Because, like, either we go back on what we say.
soispoke:And then, like, you can't really trust what we say, because the point of, like, saying things and trying to get to critical commitments and everything is, like, to stick to it. Or, we go against this
soispoke:process that now seems to be overruling every other aspect, including, like, what importance a feature brings to the table, which is just, like.
soispoke:both situations are, like, there. We need to just choose one, basically. And I think that is up to clients.
soispoke:Probably, and people in this call to decide, and I think there is no concern about, like, the community being completely taken aback by the fact that Fossili will be included in the next fall. Like, they've been asked for 5 months
soispoke:what they thought, they've participated again and again, they keep being very supportive, so I don't think there would be, like…
lightclient:Amsterdam. We didn't start the process for H-star yet.
stokes:Yeah, I mean, maybe just to jump in here, so, you know, I think the intent was we would try to find a way to commit in HECA. I think it should be clear that
stokes:We are not able to find a way.
stokes:it's… it is contentious. I think in light of that, we fall back on the process.
stokes:So, in terms of moving forward, that is what I would propose.
stokes:Yeah, essentially, we just do DFI for Glenshire Dam today.
stokes:We picked this back up with the headliner process in January for HECA.
stokes:And, again.
stokes:I think, reading the room, it should be very clear that this is a leading candidate for HECA as a headliner.
soispoke:What do you think about NSCALS?
soispoke:position to SFI without the headliner decision.
stokes:Yeah, so again, I think we should be honest about it being a headliner, and because of that, it would be sidestepping the headliner process to do this.
stokes:Which, you know, I think earlier I was more optimistic that this was…
stokes:You know, something we could do.
stokes:I think even as soon as we had the idea, it became contentious in and of itself.
stokes:So, yeah, like, I think, you know, this is the first time we're doing this headliner process, but lesson learned.
stokes:We shouldn't be trying to… yeah.
stokes:Be optimistic in the…
stokes:This way, in terms of, like, pipelining things or trying to move forward before the process has time to play out.
stokes:And…
stokes:then yeah, I think that brings us to where we are. I think, again, we just picked this back up in January.
stokes:And move forward with Glancer Dam today.
Trent:That sounds good to me.
stokes:Okay.
stokes:Then, let's do that.
stokes:And again, you know, apologies for any additional thrash or anything.
nixo:Wait, sorry, is this decision to not make a decision?
stokes:the decisions to DFI for Amsterdam, and then we would go back to the process for headliner selection in Perka.
nixo:go back to the decision to make it a CFI or a SFI today?
stokes:we can have that discussion. I think we also need to move on.
stokes:I think your proposal to CFI?
stokes:is interesting.
stokes:it does capture the community support, you know, and CoreDev's support today.
stokes:The proposal was to not do that.
stokes:Are you saying you would like to push for CFI?
nixo:I would push for a decision. At this point, I don't even care if it's CFI or F…
nixo:Specified, let's just make a decision today.
stokes:Yeah, and so what I'm saying is that we should just follow the process that we have.
stokes:We reached DF5 for Amsterdam.
stokes:And then we'll open the headliner process in January.
stokes:Also, we'll be there.
soispoke:Wait, so it's not even CFI'd?
stokes:We can CFI.
nixo:See if I… also, a bunch of people have their hands up.
stokes:Yeah, I think, like, Clan and Kesper were from previous clicks.
stokes:Potus?
Potuz:Yeah, so I support what Nex is saying. I think, kind of, CFI in it is uncontroversial. I agree with you that it seems that we cannot make… we couldn't come to consensus into making a credible commitment for next work.
Potuz:But I think there was overwhelming consensus that CFI status was granted.
Potuz:And also, that would be… give the communities at least some signal that we…
Potuz:we agreed to have this discussion, we just couldn't come to consensus on how to signal for the next fork, but we have some form of consensus. It's not that we're completely broken and we cannot agree on anything.
Potuz:And I think CFI was overwhelmingly approved.
stokes:Yeah, okay.
stokes:the CFI for HECA.
stokes:I can make the change to the MIDIP.
stokes:After this call.
stokes:Then we'll pick this back up in January.
stokes:So, to play this all back…
stokes:DFI in Glamsterdam, CFI in HECA. We'll start the Hellowner selection process in January.
stokes:Break up.
stokes:Can we move forward with this?
stokes:Okay, I'm seeing many thumbs up.
stokes:Please? Well, I don't know.
stokes:What I don't want to have happen is this happened a few calls ago, where we made a different decision on fossil, and there were a lot of thumbs up, and then we basically walked that back.
stokes:So, let me just play it back one more time, so we're on the same page, and I know this is taking a lot of time on the call. It's important.
stokes:DFI for… okay, Fossil… DFI for Glamsterdam.
stokes:Okay.
stokes:CFI.
stokes:For Hecca.
stokes:We'll start the headline process in January.
stokes:Where again, all of his support should show up, and I think it will be a very strong contender.
stokes:Or the headliner for ECA.
stokes:I think we should move on.
stokes:We're getting agreement.
stokes:Again, I know this is… been rocky and contentious, and I apologize for that.
stokes:I think we're in a good path.
stokes:From here.
stokes:Okay.
stokes:Thank you, everyone.
stokes:Well, let's move on.
stokes:Okay, we do only have… it looks like 25 minutes left.
stokes:So, let's try to get through the other EIPs.
stokes:I believe the only thing we had to touch on were these three, so 7688, which are the stable container EIPs.
stokes:And we essentially had a question of what to do with 8080 versus 8061.
stokes:I suppose we'll just go in order here. So, with 7688,
stokes:We had said we wanted to take some time to do a little more due diligence on the complexity here.
stokes:This would reach into SSD libraries, would also check…
stokes:some consensus types, in Glenser Dam, which, yeah, I think kind of has some pretty big implications.
stokes:Yeah, I would be very curious to hear from client teams if they have updated thoughts on inclusion of 7688 for Glamsterdam.
stokes:Okay, yeah, Etan, would you like to say something?
Etan (Nimbus):I mean, I…
Trent:Can't really hear you.
Etan (Nimbus):Mmm.
stokes:Yeah, your audio's pretty batty, Tom.
Etan (Nimbus):Is this better?
Trent:No, it's not better.
stokes:Yeah, maybe I can try to help here. So, there's this PDF…
stokes:And if I open it up,
stokes:Okay, so I think this looks like calling out which of the types would change?
Etan (Nimbus):Fairfield.
stokes:Yeah, it's still… I don't know, it's, like, very droppy.
stokes:Yeah, I'm not exactly sure what to make of this either.
Etan (Nimbus):Goodbye.
Potuz:It's an explanation of why the CIP… I mean, that PDF at least looks like an explanation of why the EIP is useful, in that it prevents those changes in the generalized indices.
stokes:Alright, so I think we understand the benefits of the feature, though. It's more, like, I think the question is, like, okay.
stokes:how much, like, what's the actual lift to get this implemented, and all the Z libraries, you know, I think they'll need to be tested, and then the question's also, from there, if they need to be audited.
stokes:And yeah, let me, let me rephrase that. They will definitely have to be tested, and the question is, like, what does that imply?
stokes:Do they need to be audited? Do, you know, there'll be fuzzing efforts, etc, etc.
stokes:So, I think it's… yeah, it might end up being a bit more of an ask.
stokes:Also, you know, I think getting to a place where we're touching consensus types on top of changing the same consensus types with EPBS and Clemsterdam is a little tricky.
stokes:So it's, yeah, a decision I think we should make lately.
stokes:And… yeah, I mean, I have… my own…
stokes:opinion, but yeah, I'd love to hear from client teams.
stokes:Totas?
Potuz:I just want to mention one thing about the CIP, which is… and I feel that this is getting sidetracked every time, but
Potuz:the price that we pay by not including this every fork should count as complexity that we should have saved on the previous forks. By having the CIP before, we should have saved
Potuz:complexity on previous forks, and we are always gauging this EIP against the complexity that it takes to implement for the next fork, forgetting how much we could have saved by having it earlier.
stokes:Yeah, Barnabas is asking if PRISM's pro-inclusion.
Potuz:I don't think we have a common understanding on the CIP. I don't think we have a common agreement on the team on the CIP.
stokes:Okay.
stokes:Yeah, I mean, I think, again, I think we understand the benefits. The concern is just, you know, scope and complexity that ends up
stokes:Becoming more than we think it is.
stokes:Yeah, I mean, on that point, I think it'd be good to hear from, say, Pandops, or maybe the testing teams, if they have a, you know.
stokes:Sense of the lift here.
stokes:Okay, just going over the chat here, so…
stokes:There is generally support from the client teams, which is a good signal,
stokes:Yeah, Solius has a suggestion that basically, you know, we attempt this.
stokes:Which, yeah, I… Don't know if this is the best way to do this,
stokes:Just given other attempts at process things.
stokes:But essentially, we would,
stokes:CFI, and then when there's room, you know, once it's clear what's, what's possible, then we could think about,
stokes:SFI decision.
saulius:Yeah, just… just a small note. So, I think the current process is a bit, fast, how it works, every 6 months or so. It's…
saulius:kind of, we shifted to, like, one big feature, plus, one headliner big feature, plus some small… some really small, things. And the problem I see is, in this process is that,
saulius:it becomes really hard to fit mid-size features, which are not very small, and also not a headliner feature. So I think this 7688 kind of falls into this category.
saulius:And my suggestion, of course, it's not the best in terms of the process, but
saulius:as soon as we know the actual situation with the headliner feature, this time it's going to be EPBS, which, you know, it's still… for myself, it's still not clear how long it will take all the clients to implement and test and so on.
saulius:I mean, if we see that everything is going well, then why not to include this 7688 in Glamsterdam?
saulius:But otherwise, if we see that we underestimated the complexity of EPBS, then, well, the only option is to keep the scope smaller. So that's my view.
stokes:I mean, so the question I'd have then is.
stokes:how easy would it be to take out? Because I think what will happen is we'll get to a world where there's, like, you know.
stokes:Partial implementation, like, people start moving down this branch.
stokes:And, you know, so this definitely happened with the attestation, EIP impactra, where it ended up being more, yeah, more of a lift than we thought.
stokes:But also, kind of got… The point where it was not worth it to take it out.
stokes:I do think with the CIP, the changes are pretty self-contained, so… yeah, like, it seems like we could just do this work on a branch, and then…
stokes:If it gets to that point, we could just… Discord the branch.
stokes:Does that align with client team's view of how they could go about doing this?
stokes:Burnabus?
Barnabas:So I was following in the chat, and in the chat, basically every single, CL team, said that they are in favor of, including this, so I do not see a reason
Barnabas:True.
Barnabas:further discuss it. Let's just CFI it now, and then let's move on to the next CIP, because we only have, like, 15 minutes left.
stokes:Yeah.
stokes:Okay.
stokes:That seems fair. So yeah, let's CFI7688 for Amsterdam.
stokes:And…
stokes:Yeah, I think, just, again, for the record, let's keep in mind these concerns are on complexity, and we should go about developing this in a way that it is possible to take out, if we get to a point where we feel like that's the best choice.
stokes:But people do seem to say this is, yeah, a pretty self-contained change, and it's worth reaching for now.
stokes:So, let's do that.
stokes:Okay.
stokes:So, we will see if I… 7688.
stokes:Okay, then we have the next two EIPs here, 8061 and 8080.
stokes:And… So I think at one point, there was just 8061 here. We pulled out a subset into 8080.
stokes:If Francesco's here, I would have a question, because I think, at this point, they're actually just two separate EIPs.
stokes:And I'd like to confirm that.
stokes:But then ultimately, yeah, the question is, we need to decide what we'd like to do.
stokes:The last time we touched on this, 8080, essentially would handle this edge case that we had with withdrawals and consolidated validators.
stokes:There was, you know, pretty broad support for it. The question then was, do we also want to do 8061?
stokes:Which,
stokes:adjust the term limits. And the main thing here is this just provides better staking UX, especially if you're trying to exit the set.
stokes:And I will say on this point, a number of parties have reached out from the community, so there's a comment here on the agenda from Fidelity.
stokes:Essentially saying that, yeah, this is something they're in favor of.
stokes:I also had…
stokes:someone from Bitwise reached out, who was also in support of the… so I just wanted to, again, add these quotes to the record,
stokes:In terms of their support, you know, as community approval for these… At least for AD61.
stokes:So… From here, yeah, I think we should make the decisions here. I believe I would say…
stokes:CFI 8080 is pretty… non-controversial.
stokes:Then the question is, do we want to do 8061?
stokes:So yeah, maybe to play that back, I would propose we see FY8080.
stokes:Any disagreements?
stokes:Okay.
stokes:I would also propose that we see FY8061.
stokes:And the main thing here is that it will shorten the week's subjectivity period, which is the main question.
stokes:So, I'm curious what client teams think about this.
stokes:I don't think they are Barnabas. I mean, we talked about this in the last CL call, and…
stokes:Everyone was in support.
Dustin:I do have a question regarding ADE61, about, the…
Dustin:person from Fidelity, their… their write-up, and talked about a 7-day, target, for the…
Dustin:OE subjectivity period? Where does a 7-day target come from? Like, what… as, as a…
Dustin:Because… because they framed us as… I mean, on one level, I think the correct approach was to say, what is the target? And then… then as the word, target that, as opposed to just sort of saying, we want to speed things up, and the receptivity period ends up where it ends up.
Dustin:So I… that's, I think, the more principled approach, but where does the 7 days come from, is my question.
stokes:Yeah, I mean, I think it's just adjusting the turn parameters and seeing the result, and, you know, for the turn parameters in the IP, you end up with something like a week. But yeah, Francesco, you had your hand up. I don't know if you want to add anything.
Francesco:Yeah, I mean, I had my hand up for something else, but yeah, let me just, I guess, reply to this. Like I said in the shot, the 7 days is just a number, it doesn't come from anything, but just, like, the previous number that was, like, 16 days or, you know, 15 days or something, like, doesn't really come from anywhere.
Francesco:Or, like, originally it didn't come from anywhere. But yeah, I guess what I wanted to say, originally was, like, again, this is just something that comes from the parameters that are currently in the IP.
Francesco:we can just pick whatever we want. Of course, if we just pick the current number, then, you know, the IP is kind of pointless, it doesn't do anything. But, you know, it could be 12 days, it could be 10 days, it's just, like, there's a trade-off. Of course, it's not worth doing the IP if we say, oh, let's just reduce the week-side period.
Francesco:From 15 days to 14 days, that's not gonna do basically anything, but again, it doesn't need to be 7 days.
stokes:Yeah, and then, just to be clear here, the, you know, I mentioned Fidelity and Bitwise, like, they were not involved with the CIP.
stokes:They just wanted to signal support for it.
stokes:Just so that's clear.
stokes:Mmm… Okay.
stokes:Yeah, I'm not hearing anyone say no to this. Actually, okay, no. There was a comment from Lighthouse,
stokes:Yeah, Kingy, I don't know if you'd like to say more.
kingy_sigp:Just that… just that the adjustments are, you know, it's always non-trivial when we… when we touch the consensus code, and we haven't seen
kingy_sigp:We haven't seen the specific advantages that people would like to, achieve, so… I think that we could…
kingy_sigp:We could go down the CFI path, if that's what everyone else wants to do, just that, it's…
kingy_sigp:It may not be as easy as it looks, and it's something that we… We could easily get wrong.
stokes:In terms of implementation, because I feel like this is something we have pretty good test support for, in terms of the spec test and things.
kingy_sigp:Sure.
kingy_sigp:I… yeah, sure. Look, if that's the direction everyone wants to go, that's… that's fine.
stokes:Okay.
stokes:it seems like Rough Consensus is leaning towards CF58061, but yeah, anyone…
stokes:I feel like that doesn't represent their views.
stokes:The proposal here is basically to… yeah, we can, like…
stokes:further tweak the parameters to get to, like, the period we want.
stokes:But in terms of making a decision today, we would go ahead and…
stokes:CFI, unless, yeah, the conversation goes elsewhere.
stokes:Greg.
Greg K |Lido:Yeah, so I'm a bit, confused. Like, I have the feeling that for all these IPs discussed after Fossil, there was no progress at all since the last ACDC.
Greg K |Lido:So basically, we had CFI'd all those APs, and we were waiting for…
Greg K |Lido:kind of progress in the understanding of them from, like, all stakeholders, and I get the feeling that for most of them, like, the input we had now is very small, so I was curious, like, when do… should we expect a really final SFI or DFI decision? Because I was assuming that that was today.
stokes:Yeah, so the thing that we needed today is CFI things, or DFI.
stokes:If we DFI them, then, you know, we don't think about them for Glensterdam, and we move forward.
stokes:With the CFI decisions, it's, again.
stokes:Kind of what it says. It's considered for inclusion.
stokes:The framing should be, like, yes, the intent is to put this into the fork.
stokes:From there, just in terms of process and actually, like, making this manageable to deploy, what we prefer to do is…
stokes:target the SFI set on a given DevNet, let's say, and again, to make this manageable, you kind of go one by one, so what that would look like is, again, we're right now focused on EPBS.
stokes:For DevNets, once that is good and stable, then we basically can move VIPs from CFI to SFI, so there's just a process there to get to it.
stokes:I would also push back some, I think.
stokes:Yeah, we have made progress.
stokes:again, yeah, I don't think Etan can really speak, but he did, make this, you know, diagram to call out the changes. I think people have had time to think a bit more about the implications there.
stokes:So, yeah, we made progress there.
stokes:And…
stokes:Otherwise, yeah, now we're just kind of discussing these last two. And we had already, I think, had a pretty good agreement on CFI for one, and then the question was just 8061 now with weak subjectivity.
stokes:And on that note, what I'm hearing is, yeah, other than perhaps Lighthouse with some concerns, but they're open if everyone else would like to move forward, we would go ahead and see if I…
stokes:8061 along with 8080, and then, of course, obviously, the exact parameters can be tuned as we go through the R&D process.
stokes:So… That would be the proposal. To CFI7688.
stokes:Cfi 8061 and CFI 8080.
stokes:And… That's what we do today.
stokes:Does this sound good from the client teams?
stokes:Okay.
stokes:No one seems to have an issue, so let's do that.
stokes:And… okay, we just have a few minutes left, so… to round things out, let's move to Hecca and Bogota.
stokes:And…
stokes:I think the main thing I wanted to call out today was, just a proposal here in terms of how to move forward.
stokes:with Scopian there.
stokes:So, again, this is following, the process that we've established for Glamsterdam post-Petra.
stokes:And… Yeah, the… the immediate next step is this retrospective period, following the one…
stokes:One for Picture, we now have one for Fusaka.
stokes:Which, again, we covered that earlier in the call.
stokes:Then from here, the proposal would be to essentially copy, the process from Glamsterdam, where, again, you know, we have some time for fork, fork focus and headliner proposals, then move into headliner discussion, finalization.
stokes:Then we do non-headliners, and, you know, from there, move to mainnet. So…
stokes:This Ethanitions post here is proposing a way to move forward there.
stokes:And, you know, in terms of the next, critical thing here for HECA, it would have this headliner proposal process starting January 8th. I believe this is the first ACD that we'd have in the new year.
stokes:That would go for about a month.
stokes:Then we would move to outliner selection over the next month, and move forward from there.
stokes:So, that's… that proposal.
stokes:I don't know if people have any… January 5th, okay.
stokes:then yeah, I might need to adjust the date. But that's basically the intent, is that we start the headliner discussion, just with ACD in the new year.
stokes:So… yeah.
stokes:Again, I think this is what we should do. I do think people generally feel like that liner process, you know, is productive in terms of bringing the community more involved and giving them a way to engage more productively.
stokes:So, I would propose we follow a similar process, and yeah, in terms of timing, it's pretty straightforward, just about a month per segment.
stokes:And then we move forward with Hecca and Bogota.
stokes:Any comments or questions on that?
stokes:Oh yeah?
Leo:Yes, I wanted to, mention that I want to change, I mentioned this in the Discord, I wanted to mention the
Leo:that I, I want to change the name of the star. We have been looking at this, and HECA is the first
Leo:time that this is not really a startup is located in India.
Leo:International Astronomical Catalogue of Stars.
Leo:We look for it, and…
Leo:It's kind of mentioned somewhere in a little corner in a Wikipedia page, but, yeah, and we… if we don't have, proper methodology, we, you know, we are running the risk that
Leo:Maybe in the future, we're gonna have four names that are fake, or the…
Leo:means something weird. So I would like to have a second vote for the name of the star.
Leo:And following to that, the poor mantle as well.
stokes:Okay, so you'd want to… at least the question is if we can change the name, effective.
Leo:Yeah, that's correct.
stokes:Yeah.
stokes:I don't know, I…
stokes:kind of personally would say the ship has sailed. I don't know if other people feel like we should change the name.
Leo:And there are some votes on the… on the chat.
stokes:Okay.
stokes:Hmm, okay, so… Let's see… I think in terms of moving forward…
stokes:We should take this discussion back to the naming thread that I think you linked here.
stokes:Yeah, I think what I would say is if we really want to do this.
stokes:then we should have an actual suggestion for next ACD, and make the call there.
stokes:So do you think we can do that? Like, essentially, yeah.
stokes:Because it's not part of this official list,
stokes:Sure, we can go ahead and change it if people would like to, but I think also we should go ahead and have a name.
stokes:Soon.
stokes:So there should be…
Leo:There should be a proposal for next ACD next week, and then we can change it there.
Leo:Sounds good, right? But I start a second vote, and I try to mobilize all the core devs to get a vote, and maybe by next week, we already have a vote, and then at that moment, we can decide if we change to the new, you know, most voted.
stokes:Okay, so yeah, I mean, I guess if you can show support for a new name, and you want to bring it to ACD next week…
stokes:then, yeah, I think we have a conversation there.
stokes:Yeah, does that sound good to you?
Leo:Yep, sounds good. Thank you.
stokes:And then, I think the last thing, because we are pretty much at time, but I was going to touch on the portmanteau.
stokes:I will say right now, Hikota, Hakota, however you'd like to pronounce it, is a leading candidate.
stokes:I think we need to pourmanteau also ASAP. So… Yeah.
stokes:I suppose then, let's see if we can get a proposal to change HECA next week, and if so, I'll also try to have a portmanteau to propose also as something we want to lock in.
stokes:And we would go ahead and finalize that, at the latest by next week, and then we can move forward.
stokes:Okay.
stokes:then I think we're at time.
stokes:Thank you, everyone.
stokes:For joining. I know there was a lot to cover today, and yeah, just,
stokes:Yeah, thank you. Thank you for participating, and I'll see you on the next call.
Shariq Naiyer:Have a good one, guys.
Potuz:Alright, guys.
Cayman Nava:Bye.
Pooja Ranjan:Goodbye.
Chat Logs
00:03:09
nixo:gm
00:03:15
stokes:https://github.com/ethereum/pm/issues/1825
00:04:56
Raúl Kripalani:p2p team released a first batch of daily notebooks: https://ethp2p.github.io/notebooks/ more coming soon
00:05:55
Łukasz Rozmej:@Potuz
why not save in async?
00:06:02
Raúl Kripalani:Should be fine to attest and store async
00:06:17
Raúl Kripalani:Attestation duty != custody duty
00:06:43
Pawan Dhananjay:Haven’t heard any attestation degradation reports on LH. But I doubt any of our users don’t use decently fast ssds
00:06:46
Łukasz Rozmej:if you validated it you DO want to be async
00:06:51
Dustin:It's more that until the columns are processed, the block isn't valid
00:09:10
Manu:It’s more than serving.
What about if you attest for a block and save columns async, and the client has a bug preventing it to save columns into disk?
In this case, the data is unavailable, while we voted for the given block
00:09:30
Dustin:then you don't have them
00:09:37
Dustin:until they have been persisted
00:10:10
Manu:Exactly. That’s why IMO we should not declare these columns as available before clearly persisting them to storage
00:10:28
Manu:(And so, declare the block as available, and vote for this block)
00:10:28
Dustin:It's not about the status message, only
00:11:15
Potuz:+1 Dustin
00:11:35
Carl Beekhuizen:do we have an idea of what is meant when we say these nodes have a slower disk? what kind of disk? any idea of how many nodes?
00:12:00
Potuz:Replying to "do we have an idea o..."
I know of one user’s disk, just a sec
00:12:42
Potuz:Replying to "do we have an idea o..."
SAMSUNG 870 QVO SATA III SSD 2TB
00:12:43
Potuz:Replying to "do we have an idea o..."
This failed
00:12:45
Potuz:Replying to "do we have an idea o..."
And
00:12:52
Potuz:Replying to "do we have an idea o..."
Moving to this fixed
00:12:53
Barnabas:Replying to "do we have an idea o..."
QVO’s are very slow.
00:12:53
Potuz:Replying to "do we have an idea o..."
SAMSUNG 970 EVO Plus SSD 2TB NVMe M.2
00:13:04
Barnabas:Replying to "do we have an idea o..."
QVOs can be slower than HDDs
00:13:08
stokes:https://ethereum-magicians.org/t/2025-upgrade-process-retrospective/27082?u=nixo
00:13:09
Potuz:Replying to "do we have an idea o..."
The point is that this node was performing perfectly since genesis
00:13:15
Potuz:Replying to "do we have an idea o..."
And started failing at Fulu
00:13:24
Łukasz Rozmej:Replying to "do we have an idea o..."
SATA SSD considered to slow? 😱
00:13:31
Potuz:Replying to "do we have an idea o..."
Regardless of having a slower disk, the requirements clearly changed for this node
00:13:41
Potuz:Replying to "do we have an idea o..."
And I have a few others impacted by the same
00:14:01
Barnabas:Replying to "do we have an idea o..."
QVO SSD’s are considered to be slow. Not all SATA SSD is created equal.
00:14:43
Łukasz Rozmej:Replying to "do we have an idea o..."
Max SATA speed, 100k IOPS, looks good to me: https://www.techpowerup.com/ssd-specs/samsung-870-qvo-2-tb.d17
00:15:42
Barnabas:Replying to "do we have an idea o..."
As soon as your SLC cache is exhasted your writes speeds will go down to sub 70MBps
00:16:01
Carl Beekhuizen:Replying to "do we have an idea o…"
also we require nvme drives in 7870. but in general we should have better resolution on the ssd requirements here
00:16:03
Barnabas:Replying to "do we have an idea o..."
max IOPS advertisments are a scam when we are talking about QLC type storage
00:16:04
alex (ultra sound):good summary 👍
00:16:38
Fredrik:I propose we include trustless payments
00:19:40
Justin Florentine (Besu):alex makes a good point, warrants addition to the retro thread on eth mag
00:19:44
Francesco:Q: there are still proposed modifications to this part of the spec. How long do we expect we need to agree on a final version?
00:19:46
Barnabas:I think we have already slowed down, and cycled back to this topic 2/3 weeks after we have made a decision.
00:20:15
alex (ultra sound):Replying to "Q: there are still p..."
can i find them somewhere?
00:20:42
Ansgar Dietrichs:I think at this point it is likely too late to revisit the decision, at some point it needs to be final.
I will say though, as a point of criticism of the EIP champions, given how important a headliner is, I found remarkably little willingness to consider adjustments earlier into the process. That was a failure in my opinion.
00:21:02
nflaig:if we wanna ship the fork fast I think we should split it out into H* and also allow more feedback on the design, if we wanna ship in Glamsterdam we should consider all feedback and take into account that shipping the fork might take longer
00:21:16
alex (ultra sound):existing ecosystem will be disrupted to some extent i think. still researching what it’ll mean exactly but i foresee some real work to be done before we settle in a new equilibrium for how most bids are sourced.
00:21:22
hangleang:Replying to "Q: there are still..."
the sooner we can freeze the spec, the better
00:21:43
Justin Florentine (Besu):Replying to "I think at this poin..."
thats a tough assertion to make. I saw the same, but didn't feel that adjustments were not fairly considered.
00:22:40
Justin Traglia:Replying to "Q: there are still p..."
At least a few weeks from today, given the holidays. There are some things we’d like to explore like staked builders without validator duties so they can make faster deposits. But I would consider these to be optimizations/improvements.
00:22:43
Dustin:Replying to "I think at this po..."
I thought Potuz was remarkably open to contributions/changes
00:22:58
Dustin:Replying to "I think at this po..."
It's been ongoing for literally years now
00:23:22
Potuz:Replying to "Q: there are still p..."
These are big changes though
00:23:35
terence:Replying to "Q: there are still p..."
what changes here?
00:24:00
christophschlegel:Replying to "I think at this poin..."
Potuz presented at Flashbots and was very open to our opinion. Seems just that MEV ecosystems and devs operate on different timelines.
00:24:13
Francesco:Replying to "Q: there are still p..."
It doesn’t feel like we should be exploring things at this stage though?
00:24:25
Francesco:Replying to "Q: there are still p..."
This is exactly why this part of the EIP should have been split up btw...
00:25:42
Justin Traglia:Replying to "Q: there are still p..."
We’re trying to work with builders to make things better for them. Compromises.
00:26:04
Justin Florentine (Besu):i think this is a fair case, but seems like it is an iterable impovement
00:26:25
Justin Florentine (Besu):i.e. ePBS 1.1 in a later release
00:26:40
Justin Traglia:Call out for the next ePBS breakout call: https://github.com/ethereum/pm/issues/1835
00:27:08
Francesco:In Fusaka we spent ~a month discussing getBlobsv2 versus v3, which was a tiny decision. I am worried that this will drag on, especially since it’s not an isolated decision, it affects builders, it touches a few things in the spec etc...
00:27:51
Quintus Kilbourn:Taking away the 32 eth minimum and allowing deposits to go faster keep capital requirements down which is good for keeping the market easy to participate in
The only other major thing to say is that we really should do as much as possible to avoid using p2p for bidding (great for WW3 but undesirable for everything else)
00:27:52
Francesco:I am sure we’ll sort it out eventually, just doesn’t seem like a small thing
00:28:00
Potuz:Replying to "In Fusaka we spent ~..."
My general take on these things is to by default not change things like this big when they are already in motion, but at least we want to be exploring how bad of a change it would be
00:28:09
Potuz:Replying to "In Fusaka we spent ~..."
It could be this fork or the next one to iterate over this
00:28:10
Justin Traglia:Replying to "In Fusaka we spent ~..."
There was also the new transaction type, with cell proofs instead of blob proofs. That happened pretty late into the process, no?
00:28:33
Francesco:Replying to "In Fusaka we spent ~..."
That happened a few months before Pectra went live
00:29:24
Trent:Bump for @Ansgar Dietrichs to reaccess after dropping
00:29:45
Potuz:Replying to "Taking away the 32 e..."
I think we want to have a decentralized set of p2p bids, they aren’t really a problem for the proposer cause they’ll get just a few of them already heavily filtered
00:31:57
gd:I think as long as there is an alternative path to validators p2p is fine. p2p becomes a bit more of a concern if it is the only option to reach a large enough portion of the stake
00:32:26
Justin Florentine (Besu):so that framing is assuming that the door is closed to FOCIL in Glamsterdam.
00:34:07
Toni Wahrstätter:Replying to "so that framing is a..."
Which is reasonable, imo. ePBS and BALs are both big features and we shouldn't do 3 big features in one fork.
00:34:36
nixo:it’s not ‘process for the sake of process’ - client teams have indicated support for focil in glamsterdam but the rest of the ecosystem hasn’t really had the opportunity. they need a ‘process’ to know how to participate
00:34:51
Justin Florentine (Besu):Replying to "so that framing is a..."
i agree, but disagree that we can't take more time on a fork. i'm not sold on the 6th month cadence being inviolable.
00:35:31
nixo:imo FOCIL should be CFI’d and then we should set this heka(?) timeline definitively so there’s clarity
00:35:54
Francesco:Replying to "I think at this poin..."
Two things are true imo:
Potuz (and Terence and others) did a great job at engaging with all kinds of stakeholders repeatedly, over a long period of time.
Earlier in the decision process, the discussion became more charged than it should have been because people felt that trustless payments would either get in now (on the wave of epbs’ scalability features) or never (similar dynamics to FOCIL). People saying that trustless payments could be split from the other features and raising concerns around complexity were ignored or treated as lacking Ethereum values
00:36:14
Ansgar Dietrichs:I personally would be open to FOCIL sfi now - but I don’t think it would be appropriate to assign it headliner status before starting the headliner process. That would be unfair to other potential headliner proposals.
In practice ofc good chance we then decide there is no room for a(nother) CL headliner, but that should be during a proper headliner scoping process.
00:36:37
soispoke:Replying to "I personally would b..."
So SFI FOCIL as a non headliner?
00:36:40
Trent:I dont know if we need to argue the benefits of FOCIL (or any other specific EIP) right now, we’re talking about the process
00:36:58
Ansgar Dietrichs:Replying to "I personally would b…"
SFI without assessment of whether headliner
00:37:12
Justin Florentine (Besu):one users censorhip is another users whitehat rescue
00:37:24
Francesco:Replying to "I think at this poin..."
(And to be clear I am not saying that this was all on Potuz or someone, it’s partially just the governance dynamics that can turn unhealthy when something is contentious)
00:37:28
Potuz:FWIW, that paper doesn’t talk about FOCIL but MCP
00:37:40
Potuz:The assumptions on FOCIL are different 🙂
00:37:43
terence:Yes
00:37:46
terence:It's very different
00:37:54
nixo:Replying to "I personally would b..."
the first SFI is the headliner status
00:37:54
Dustin:Yeah, I don't think right now the argument was, is FOCIL good or not?
00:38:10
Dustin:There wasn't really disagreement about that part
00:38:14
Potuz:Except Matt 🙂
00:38:57
Ansgar Dietrichs:Replying to "I personally would b…"
It’s less of a bending of process to change that than to decide to skip an entire headliner process
00:39:03
Toni Wahrstätter:Feels like the majority agrees that focil has merits.
This doesn't change the fact that glamsterdam is already big and that we should stick to the process to give other eips the same chance as focil in heka.
00:39:40
nixo:Replying to "I personally would b..."
i don’t understand your message
00:39:55
Francesco:Replying to "I personally would b..."
The process is a few months old, so not exactly sacred, and at the end of the day the process serves Ethereum goals, not itself. Still, SFIng something before the headliner process makes the headliner process fairly meaningless
00:41:08
donnoh | L2BEAT:the takeway i wanted to give is that i dont think we should SFI until we properly understand the benefits and right now we dont 😅
00:41:19
Dustin:Yeah, also I think we'd already agreed that it's nto in Glamsterdam, that's not the point of contention anymore
00:41:26
Barnabas:I have really bad deja vu about FOCIL discussion.
00:41:42
Toni Wahrstätter:Replying to "There wasn't really ..."
We should also involve rollups in the discussion who will not get CR from focil, or at least flag it publicly that blobs won't be supported.
Same for starks that are too big to fit into ILs.
Talking to people, this isn't clear to many.
00:41:43
Dustin:It's literally, is it CFI or SFI
00:41:44
Dustin:that's t
00:42:23
Potuz:Do we have a timeline set for the headliner process? Tim had posted for Gloas a list of dates up until when the headliner would be accepted for being proposed, when discussions started, etc.
00:42:42
Toni Wahrstätter:Replying to "Do we have a timelin..."
Process-wise, january?
00:42:42
Caspar Schwarz-Schilling:To me the clear take-away from last ACDC was that clients should decide whether to SFI FOCIL for Heka on this ACDC. Why change this now? Let‘s just do this.
00:42:49
Ansgar Dietrichs:But we considered it very seriously as a non headliner for Glamsterdam as of 2 calls ago
00:43:06
Potuz:Replying to "Do we have a timelin..."
If we’re talking about a couple of weeks then it’s probably a waste of time anyway to decide anything now?
00:43:12
nixo:Replying to "Do we have a timelin..."
https://ethereum-magicians.org/t/eip-8081-heka-bogota-network-upgrade-meta-thread/26876
00:43:20
Ansgar Dietrichs:Replying to "But we considered it…"
I do agree it will likely end up as a headliner. That’s fine. No need to make that decision today
00:43:24
Ladislaus:Hat auf "To me the clear take..." mit 👍 reagiert
00:43:39
nflaig:FOCIL is orders of magnitude simpler than peerdas or epbs so I think it can definitely be a non headliner
00:43:41
Justin Florentine (Besu):Replying to "But we considered it..."
sorta. i think that consideration hinges very much on a non 6-month cadence.
00:43:43
Francesco:That is something I agree with though, the headliner process is a bit weird with things like FOCIL
00:44:07
Potuz:Replying to "Do we have a timelin..."
Oh thanks Nixo, I looked in forkcast instead 😅
00:44:13
sean:can we do FOCIL + shorter slots?
00:44:17
Ansgar Dietrichs:Replying to "But we considered it…"
Right, but as of 2 calls ago that seemingly was a price we were potentially willing to pay
00:44:42
Potuz:Replying to "can we do FOCIL + sh..."
I honestly disagreed with Pari here, I think FOCIL+shorter slots is even harder than FOCIL+ePBS
00:44:57
NC:Replying to "FOCIL is orders of m..."
I don’t think a headliner candidate is weighted by its technical complexity but the influence it brings
00:44:58
soispoke:FOCIL is definitely not as big as ePBS though
00:45:17
Toni Wahrstätter:Replying to "can we do FOCIL + sh..."
I feel like we shouldn't, with regards to complexity
00:45:27
Justin Florentine (Besu):Replying to "But we considered it..."
yes, and so that would be the process point we should be discussing
00:45:29
donnoh | L2BEAT:Replying to "There wasn't really ..."
it’s not only starks but some fraud proof system bisection steps can also be very big
00:45:49
sean:basically SFI'ing FOCIL without it being explicit about what we're giving up is basically the problem with doing it early
people def want shorter slots and we would be avoiding that discussion
00:46:27
Toni Wahrstätter:Replying to "There wasn't really ..."
Right, should we sfi anything before those affected (by not being able to use it) are at least aware?
00:46:38
Mehdi Aouadi:SFI it now and do the headliner process. If FOCIL is selected as headliner , fine, otherwise let it be just SFI’ed with another headliner. At least that way we will be carefull while selecting the hadliner if not FOCIL
00:46:46
Fredrik:How much time are we talking of between now and being able to SFI according to the process?
00:46:56
stokes:Replying to "How much time are we..."
A few weeks
00:47:03
Ladislaus:Hat auf "SFI it now and do th..." mit 👍 reagiert
00:47:08
soispoke:Replying to "SFI it now and do th..."
Yeah exactly
00:47:16
Potuz:Replying to "How much time are we..."
Yeah that was my question above, I think this all may be a waste of time if in a couple of weeks we’ll be discussing anyway
00:47:33
Ansgar Dietrichs:Replying to "But we considered it…"
Well yes, but I would argue not today as part of Glamsterdam scoping. We should keep the process deviation minimal. CFI or SFI FOCIL for H* today, then have the conversation about headliner status and 6-month cadence during the H* headliner process we will start soon
00:48:13
sean:Replying to "SFI it now and do ..."
I was just trying to get at, you can't do this with some EIPs if another one is complicated enough, for example shorter slots people don't think is possible
00:48:23
sean:Replying to "SFI it now and do ..."
you can't really make the decision in isolation
00:48:26
Francesco:Given that most people do want FOCIL to be included and there’s this history etc… and the headliner process is soon, why not just follow the process and select it in a few weeks that way though, rather than bending the process?
00:48:50
Francesco:(At the moment it also seems clear that it is much farther than 6SS in maturity, so it seems hard to imagine that this is not what we end up with in a few weeks)
00:48:52
Barnabas:Can we timebox FOCIL pls?
00:48:54
Trent:We are again edging into retrospective discussions about process over the last few weeks instead of moving forward
Can we agree to just start the broader process ASAP?
00:48:57
Potuz:To me the bulliest case of FOCIL I have heard is that the current censors want it so that they can stop censoring
00:49:25
Mario Havel:FOCIL is something really worth committing to and should not become a victim of the process we are still discovering
00:50:07
Toni Wahrstätter:It has the size of a headliner and we've closed glamsterdam.
The next step would be doing the headliner process in a few weeks and see where we land by then.
00:50:38
terence:TIL: txns from the public mempool that are included in some blocks, 17% are not in the winning block. (https://x.com/soispoke/status/1999095871435137396 )
00:50:46
Toni Wahrstätter:Replying to "FOCIL is something r..."
That's your take. Others will say differently or have different priorities
00:51:06
soispoke:Replying to "TIL: txns from the ..."
Caveat dataset is small but yeah was surprised by this as well
00:51:07
Mehdi Aouadi:Replying to "SFI it now and do th..."
that reasoning doesn’t take into account that FOCIL already got more support than any new EIP, has a working prototype and has already been discussed… It’s unfait to just forget everything and reset the process
00:51:34
Francesco:Replying to "SFI it now and do th..."
These things are still true though, and why very likely FOCIL will be selected
00:51:35
sean:We can put resources into it regardless of SFI status
00:51:38
Cayman Nava:imo focil can't make additional engineering progress until its rebased on ePBS (likely lines up with headliner process?)
00:51:53
Francesco:Replying to "SFI it now and do th..."
It’s not that in a few weeks we forget that it has a lot of support and mature specs etc…
00:52:07
Toni Wahrstätter:Replying to "To me the bulliest c..."
Yeah, bc we shift responsibility to validators. You should talk to them too.
00:52:11
Justin Florentine (Besu):Replying to "We can put resources..."
thats not generally realistic, existing SFI'd features tax teams.
00:53:08
Ansgar Dietrichs:So seems like we have 3 options:
CFI
SFI without deciding whether headliner
SFI as headliner
00:53:10
soispoke:I think the same arguments were said for Glamsterdam: we all like FOCIL but we don’t want to include it now
00:53:11
terence:Side comment: FOCIL on top of epbs may not be as simple as ppl think. The forkchoice part is the biggest complexiity. Epbs add the notion of empty payload slot so when focil reorg, it needs to consider parent hash as well
00:53:26
sean:Replying to "We can put resourc..."
Usually SFI'd stuff is further along tbf.. but we've already had Eitan on our team implement it and I'm sure he'd love to keep pushing it
00:53:56
nflaig:Replying to "It has the size of a..."
how is "size" defined here, in terms of LoC it's tiny (~2,5k) compared to other headliners like peerdas which was 20k+ LoC
00:54:18
Francesco:Replying to "I think the same arg..."
I think the clear message is that we do want to include it now (for H*, as a headliner) though
00:54:20
Pawan Dhananjay:Replying to "We can put resources..."
Tbf, 6 second slot is heavier on the testing side than implementation side
00:54:28
Trent:Can we please timebox
00:54:29
Justin Florentine (Besu):Replying to "We can put resources..."
huh, see i see the fact that multiple clients have focil impls means it should be SFId to reflect reality
00:54:30
DA | Flashbots:Replying to "TIL: txns from the ..."
I don’t trust those stats. Certainly not reflective of what I’ve seen. Unless these are just late tx or 0 fee spam.
00:54:37
stokes:Replying to "Can we please timebo..."
Yes, Matt and then that’s that
00:55:32
soispoke:We’ve been discussing for 5 months though
00:55:45
DA | Flashbots:Replying to "TIL: txns from the ..."
Would be curious to look at our internal stats.
00:55:51
Toni Wahrstätter:Replying to "It has the size of a..."
Touches both layers, adds extra deadlines, complex, many small "hacks" (no blobs, no fraud proof support (too large, no stark support). Those things add up.
00:55:59
sean:Replying to "We can put resourc..."
there's a 6s impl too though
00:56:16
Ansgar Dietrichs:So how are we going to make the decision today?
00:56:22
Jihoon:Replying to "Side comment: FOCIL ..."
Good point, it's something we want to keep in mind. But still it doesn't change that FOCIL is probably the most mature and well-researched EIP among headliner candidates
00:57:14
nixo:+1, ‘process’ should be independent of what we want, that’s the only way we have a good process. we can’t adjust the process based on what specific features we want in the next fork, that creates a bad process
00:57:58
Toni Wahrstätter:6ss is "easy" to implement but needs time to do proper analysis, e.g. around geo decentralization.
6ss is as far as focil when it comes to understanding technical impact.
What is needed is more analysis.
00:59:29
NC:Replying to "+1, ‘process’ should..."
True, but take into account that this process is relatively new and there is room to improve the process. Generally agree your point
00:59:36
Trent:IMO it was a mistake to try and poll client teams as a way to get this early "credible commitment”
Mistakes were made. Start the process
00:59:45
Ansgar Dietrichs:If we SFI without headliner decision, we are only telling the community "heads up, next fork the CL side will have less room for changes, so take that into consideration when you participate in the public scoping process" - that’s fine imo, much better than "sorry, headliner was already secretly pre selected"
01:00:00
Pawan Dhananjay:Replying to "We can put resources..."
Yeah exactly, implementing 6s on a client doesn’t say much in terms of having it “ready”
01:01:03
Toni Wahrstätter:Agree with matt. We shouldn't exploit loopholes in the process, sidestepping it, or turn this (technical) decission into what is happening right now
01:01:18
Jihoon:Replying to "We can put resources..."
As a person who has built the 6s prototype, I don't think we understand 6s's technical impact as much as FOCIL. Unlike FOCIL, 6s has the nature that we should analyze 2nd and 3rd order impact similar to EIP-7549. Having running prototype that is running in a "local" environment doesn't really tell us much on its technical impact.
01:01:33
sean:Like are we afraid discussion in the future will yield a different result?
01:02:00
nixo:we have to make a CFI or SFI decision??
01:02:27
Barnabas:Replying to "we have to make a CF..."
we will do headliner selection in the new year
01:02:36
Justin Florentine (Besu):DFI
01:02:37
Francesco:Replying to "Like are we afraid d..."
That’s the concern, which is reasonable given how unpredictable ACD as a forum is 😅 However all of these discussions are just accumulating “evidence for the future”
01:02:41
Justin Florentine (Besu):but heka soon
01:02:49
soispoke:So no CFI or SFI?
01:02:52
soispoke:For Heka
01:02:52
Dustin:so not CFI?
01:02:58
Barnabas:I don’t think it matters
01:03:00
Barnabas:lets just move on
01:03:26
Potuz:+1 Nixo
01:03:43
Barnabas:Lets go.
01:03:44
Milos:In my opinion, CFI/SFI for Heka doesn't mean much. If Headliner is something else, it can cause FOCIL to be DFI-ed from Heka as well (e.g. due to complexity)
01:03:49
Justin Florentine (Besu):sounds perfectly cromulent
01:03:50
Dustin:This is pretty disingenuous relative to the claim made a couple of weeks ago
01:04:12
Hsiao-Wei Wang:Does CFI need EL teams’ confirmation?
01:04:18
Milos:Replying to "In my opinion, CFI..."
To clarify, I support FOCIL as headliner.
01:04:27
soispoke:Replying to "Does CFI need EL tea..."
They were supportive of SFI last ACDE
01:04:29
Pawan Dhananjay:I thought it was CFId already
01:04:33
kingy_sigp:Lighthouse supports CFI until we do headliner discussion
01:04:41
Francesco:Replying to "I thought it was CFI..."
Yeah wasn’t it?
01:04:50
soispoke:Replying to "I thought it was CFI..."
I thought it was
01:04:52
Justin Florentine (Besu):Besu CFI'd focil in G*, same for H*
01:05:14
Ansgar Dietrichs:Replying to "Does CFI need EL tea…"
EL teams also were a bit tired of constant ping pong with ACDC, so I think they would prefer a decision today
01:05:37
sean:Replying to "Like are we afraid..."
if changes require consensus I don't get how a different result is even a bad result. in theory more people should be involved in January
01:05:53
Toni Wahrstätter:SFI would be too early. People want shorter slots too. And saying we delay CR features - as we _always_ do - is wrong. It's barely a one year old eip.
01:06:05
Ansgar Dietrichs:Can we check, are the people that preferred SFI okay with CFI as a compromise?
01:06:12
Barnabas:Replying to "Can we check, are th..."
no
01:06:17
Barnabas:Replying to "Can we check, are th..."
We need to move on
01:06:19
nixo:Replying to "Can we check, are th..."
no
01:06:33
Ansgar Dietrichs:Replying to "Can we check, are th…"
Well check as in, check here in chat
01:06:57
Potuz:Replying to "Can we check, are th..."
No, but it seems that we’re not going to be able to agree on SFI today, so CFI is the best option we have
01:07:04
Justin Florentine (Besu):Replying to "Can we check, are th..."
i'm confused because we spent a lot of time talking about adhering to process, and I guess PFIs are open for Heka now?
01:07:27
Ansgar Dietrichs:Well either way - welcome CFI’d FOCIL to H*! 🙂
01:07:30
Potuz:Replying to "Can we check, are th..."
Yes, PFI had never a start date AFAIK
01:07:39
Etan (Nimbus):7688 implementation complexity due diligence:
https://github.com/user-attachments/files/24103859/7688.pdf
01:07:40
Justin Florentine (Besu):Replying to "Can we check, are th..."
good enough I'll take it
01:07:53
Potuz:Mic dao
01:07:54
terence:micdao
01:08:22
Justin Florentine (Besu):fiber-to-the-mic dao
01:08:44
Barnabas:Time to get out of the tunnel Etan
01:08:48
nixo:🙁 etan, it’s so bad that it’s impossible to understand
01:08:53
kingy_sigp:For 7688 we think it is not insignificant in terms of scope but is worthwhile including. Lighthouse would support its inclusion in glamsterdam.
01:09:24
Barnabas:any other CL teams?
01:09:26
Etan (Nimbus):last slide of the pdf
01:09:32
Cayman Nava:Lodestar would support inclusion in glamsterdam (with the asterisk that it drop if it causes fork delays)
01:09:34
Dustin:Nimbus supports, obviously
01:09:34
NC:Lodestar supports
01:10:13
Greg K |Lido:Lido supports 7688 (SFI)
01:10:15
Etan (Nimbus):Replying to "Time to get out of t..."
joining from a hotel lobby...
01:10:32
Barnabas:@Potuz is prysm pro inclusion ?
01:10:36
Etan (Nimbus):in any case, let me write here
01:10:41
Dustin:+1 to Potuz's point
01:11:07
Etan (Nimbus):no serialization change (network / db same), only hashing change
length checks move to the p2p rules
01:11:08
Barnabas:Can we have a prysm stance on this by end of this call?
01:11:19
saulius:Grandine suggests to attempt inclusion of 7688 in later devnet-3/4 when it will be clear that there is room for it in Glamsterdam.
01:11:24
Etan (Nimbus):tests are on par with existing SSZ
tests for new max length also exist
01:11:29
Barnabas:I don’t understand how we don’t have a team’s stance on each open EIP at this point
01:11:50
Dustin:Replying to "Grandine suggests ..."
There weren't that many devnets targeted for Fusaka, they failed so there was a devnet 5/6
01:11:59
Enrico Del Fante (tbenr):I think we should go for it
01:12:04
Mario Vega:Wait is this EL? no, right?
01:12:08
Dustin:Replying to "Grandine suggests ..."
that's extremely late
01:12:09
Etan (Nimbus):it’s CL
01:12:43
Dustin:How is the current process "fast"? EIP-7688 has been around for years
01:13:40
Greg K |Lido:I had the impression that Prysm supports 7688 (see ACDC - NOv 13th): https://github.com/ethereum/pm/issues/1790#issuecomment-3524246616
01:14:07
terence:prysm team supports EIP-7688 per team agreement: https://github.com/ethereum/pm/issues/1790#issuecomment-3524246616
but i do echo Cayman's feedback that we should drop it there's extensive delay
01:14:33
Cayman Nava:It's trivial to remove for Lodestar. We have changes in the client segregated to the types ProgressiveContainer -> Container
01:14:42
Etan (Nimbus):yeah it’s quite self-contained imo, mostly in library
01:15:18
Etan (Nimbus):also, let’s use #ssz channel to discuss any tech challenges about it
01:16:19
Potuz:Yes they are separate
01:16:23
Potuz:They have no intersection now
01:16:47
Francesco:I am here
01:17:14
Justin Florentine (Besu):Fidelity?
01:17:44
kingy_sigp:lighthouse supports 8080
01:18:02
Dustin:sure, 8080 is fine
01:18:19
Barnabas:is any CL team against CFI 8080?
01:18:52
Potuz:We support it if people agree with the WSP decrease safety assumptions.
01:19:05
saulius:Replying to "Grandine suggests to..."
devnet-2 works too :)
01:19:06
kingy_sigp:At this time we don't support 8061 as adjustments to consensus code are non-trivial. If there are specific advantages people want from 8061 we would want to see them because at the moment it doesn't seem worth it to us.
01:19:16
Francesco:It doesn’t come from anywhere, it’s a magic number like the previous number 😅 I don’t know about this fidelity thing though
01:19:18
Cayman Nava:I had thought that the existing ws period at 2 weeks mirrors our "worst case" timeline for coordinating around bad network conditions
01:19:35
Francesco:To be clear I wrote the EIP, without input from fidelity or whoever
01:19:43
NC:Regarding shorter WS period, we should ask the broader community because they run the nodes and whether 7 days is enough for them
01:19:52
saulius:Replying to "Grandine suggests to..."
I just want to get all the clients interoping on devnet-1 with epbs first.
01:20:22
stokes:Replying to "To be clear I wrote ..."
Yes, im just calling attention to this comment
https://github.com/ethereum/pm/issues/1825#issuecomment-3640072332
01:20:32
Barnabas:I think we should CFI the EIP, and bikeshed the exact value
01:20:46
Dustin:Replying to "To be clear I wrot..."
Right, I'm not saying Fidelity was involved in writing the EIP
01:20:48
Potuz:Replying to "I think we should CF..."
I agree
01:20:55
Phil Ngo:Replying to "I had thought that t..."
IIRC, it also mirrored around how long we kept blobs around for as well.
01:20:56
Francesco:Replying to "To be clear I wrote ..."
Yeah just wanted to clarify
01:21:44
Francesco:The main advantage is not having a 40 day withdrawal queue 😄 In combination with 8080, it would be like 5 days or something
01:21:52
Francesco:Replying to "The main advantage i..."
(With current amount of eth in the queue)
01:22:59
Francesco:Also consider that the benefits are actually greater for home stakers or anyway stakers other than LSTs and staking pools, because the in-protocol exits is all they have
01:23:21
Barnabas:SFI is when we we have them on devnets
01:23:28
Barnabas:thats probably still at least a month away
01:24:21
Potuz:Replying to "I had thought that t..."
But that was the other way around
01:24:27
Potuz:Replying to "I had thought that t..."
We chose the blob retention period because of that
01:24:32
Francesco:Replying to "I think we should CF..."
I would support this, and I am very much open to more conservative values. Just we have to be mindful that it doesn’t make sense to do the EIP if we don’t decrease the WSP meaningfully (like at least to 12 days or 10 days or something)
01:24:54
Barnabas:2048 epochs sounds pretty good to me (9d)
01:25:10
Potuz:Replying to "I think we should CF..."
I looked into the implementation and it seems simple enough to justify implementation to at least have some testing already done
01:25:29
Francesco:Replying to "I had thought that t..."
Yeah the WSP existed from the beginning, before blobs. Unfortunately I wasn’t around back then and from the documents I read I can’t find a clear motivation for 15 days other than it being a somewhat meaningful social coordination period
01:25:33
Potuz:Replying to "I think we should CF..."
Doubt we’ll get much bikeshedding against a week for WSP unless some real P0 appears
01:25:37
Barnabas:Time to get to work!
01:25:40
terence:sounds good to me
01:25:42
kingy_sigp:That's fine
01:25:52
Phil Ngo:Let’s get to work!
01:25:58
Francesco:Great! Thanks everyone
01:26:16
stokes:https://ethereum-magicians.org/t/eip-8081-heka-bogota-network-upgrade-meta-thread/26876?u=ralexstokes
01:26:37
Potuz:Is there ACDE next week?
01:26:44
Barnabas:Replying to "Is there ACDE next w..."
yes
01:26:48
nixo:Replying to "Is there ACDE next w..."
yes
01:27:35
Barnabas:Jan 5 is the first ACD
01:27:56
nixo:Replying to "Jan 5 is the first A..."
oh that’s ACDT?
01:28:10
nixo:from leobago at MigaLibs in the R&D discord:
> I noticed the name voted for the hard fork after Glamsterdam was Heka - Bogota. All of the star names we have selected are in the official list of star names given by the International Astronomical Union [but Heka isn't a real star name]
> If there are no strong objections to this, I would set up a second vote for H, with only names from the catalog.
other options:
https://ethereum-magicians.org/t/h-star-name-for-consensus-layer-upgrade-after-glamsterdam/24298/15
full conversation in the #uncategorized channel
emoji react
🌟 to choose a proper star name
🤷 to just move forward with Heka even tho it's not a real star name
01:28:19
Barnabas:Replying to "Jan 5 is the first A..."
You telling me ACDT is not a real ACD ? 😄
01:28:36
nixo:Replying to "Jan 5 is the first A..."
i would never
01:29:24
nixo:emoji reacts are winning to choose a real star name
01:29:53
nixo:i just ask that the decision is made by next ACD? thurs
01:29:57
Barnabas:I think we can really quickly change a new name, shouldn’t get stuck on this. If its not a real star, its kinda dumb lol
01:30:13
Potuz:lol
01:30:16
Justin Florentine (Besu):to soon to headline, to late to rename
01:30:22
Ansgar Dietrichs:Replying to "Jan 5 is the first A…"
We were thinking about having that ACDT as an ACDE replacement, given ACDE Jan 1 is cancelled
01:30:25
terence:did we have a credible commitment to star name
01:30:35
Trent:Not now terrenceeee
01:30:35
Potuz:I still call it the H fork
01:30:47
Barnabas:we should trust the process
01:30:47
Ansgar Dietrichs:Replying to "Jan 5 is the first A…"
In case that would be acceptable from the ACDT side
01:30:48
NC:Replying to "to soon to headline,..."
We are in a mysterious timeline
01:30:55
jochem-brouwer:Antwoord verzenden naar "I still call it th..."
H star!!
01:30:55
kingy_sigp:do we need star headliner process
01:30:58
Justin Florentine (Besu):yes, but the process is still forming, like a protostar
01:31:04
felipe:Let's name a star Heka and propose it officially?
01:31:13
Justin Florentine (Besu):Replying to "Let's name a star He..."
brilliant
01:31:13
Ansgar Dietrichs:Replying to "Jan 5 is the first A…"
Given the significant remaining EL scoping work ahead
01:31:25
Barnabas:+1 Hunor
01:31:57
nixo:portmanteau by next ACDE
01:32:00
Justin Florentine (Besu):Replying to "+1 Hunor"
Hugota 🫂
01:32:00
Josh Davis:Will be dependent on the star, no?
01:32:10
Barnabas:Replying to "Jan 5 is the first A..."
I think we can do that.
01:32:10
kasey:Still sad it didn’t line up so we could have hamsterdam
01:32:19
Barnabas:Replying to "Jan 5 is the first A..."
Do we need a credible commitment for the swap?
01:32:30
Justin Florentine (Besu):Replying to "Still sad it didn’t ..."
this guy The Wires
01:32:36
Ansgar Dietrichs:Curious what we will do in 10 years when we will run out of letters
01:32:44
dionysuz.eth:thank you alex
01:32:54
Mario Vega:Replying to "Jan 5 is the first A..."
If you put the discussion in the agenda for Jan 5 we can just do it
Summary
13 highlights
· 5 decisions · 2 action itemsExperimental
Summary
13 highlights · 5 decisions · 2 action itemsExperimentalfork status and schedule
client updates
glamsterdam scoping
- Trustless payments kept in ePBS; no security issues found00:17:41
- Exploring non-validating staked builders to address deposit churn concerns00:23:44
- FOCIL: DFI for Glamsterdam, CFI for H-star; headliner process starts January01:05:11
- EIP-7688 (stable containers) CFI'd with CL team support01:15:00
- EIP-8080 and EIP-8061 (churn/weak subjectivity changes) both CFI'd01:25:05
Decisions
- Trustless payments stay in ePBS; only revisit for clear security issues00:20:34
- EIP-7805 moved to DFI for Glamsterdam01:05:11
- EIP-7805 moved to CFI for Heka01:05:11
- EIP-7688 moved to CFI; develop to allow removal if complexity issues arise01:15:00
- EIP-8080, EIP-8061 moved to CFI; weak subjectivity parameters tunable01:25:05