All Core Devs - Consensus #172

Transcript

Alex Stokes: Hello, everyone. Happy New Year. Okay, let's wait, about 2 more minutes, and then we'll get started, just as people… Keep streaming in.

Can everyone hear me? I'm just doing a mic check. Okay, thanks. Sometimes I have issues with my headphones.

Justin Florentine: Happy New Year, Ethernauts! 2026, let's go!

Alex Stokes: Happy New Year. It was a great intro from Justin. Okay, Josh, if you're helping with the stream, then I think we're ready to get started.

Josh Davis: Alright, Alex, go ahead of your life.

Alex Stokes: How are you, thanks. Happy New Year, everyone! This is the first ACDC of 2026. It is call 172. Let me grab a link to the agenda, I'll put it here in the chat. So, yeah, today, a couple things to cover, a few quick announcements, then we'll touch on Fusaka, Glamsterdam, and Hegota. So… Let's get into it. I put these announcements first, because I think they should be pretty brief. The first one is just a shout-out for a breakout on the task confirmation rule. Let's see, is either Roberto or Mikael here to say something about that?

Mikhail Kalinin: Hey, I'm here. Happy New Year, everyone. So… There is a fast confirmation rule, there is a PR that is open to the spec. And, we actually plan to… to have a… a couple of production-ready implementations in CL clients in a couple of months, like, by this beginning of March. And in order to facilitate the development of implementations, we want to introduce breakout calls. Where we can discuss the progress, the challenges that developers see in implementing the algorithm, also incorporate feedback into this fact. And, yeah, just basically share, the progress on tests and all these kind of things. And, these breakout call sessions, will be bi-weekly and start on January 20. In the meantime, we… it's a bit of an update, from…

the spec and spec development side and testing side. We work on tests currently, so the spec is, Let's say it's kind of final, but it will be final after more developers' feedback will be incorporated into it, so we need more eyes from developers. But it is final, it is ready to get implemented, and we are working on tests, and a bunch of tests with decent coverage will be ready by By the beginning of February, by the end of January, Some kind of that. So this is our main priority now on this fast confirmation thing. Yeah, that's… that's probably it. Maybe, Will can add anything on that?

Will Corcoran: No, we'll just be alternating, Tuesdays with, I forget, maybe a FOCIL, breakout room, so it's gonna be the first one starting tuesday, January… I forget, the 20th, I believe? It's at 2 p.m. UTC, and yeah, we'll… We'll be running every other week.

Alex Stokes: Okay, sounds good. Thank you both for the update. So, yeah, very exciting work there. If you're interested to dig in deeper, join the breakout. Okay, next, I don't know if Nixa's here, but she had a comment, she actually worked at the PR, but I guess she and some others have been working on, refining this notion of champion. It's a document in the PM repo, I'll just grab a link to the PR here. And I think, for now, it's essentially a request for comments. So, take a look at that if you would like to contribute there. Okay, so I think those were all the announcements we had, and yeah, let's then turn to Fusaka. So… We did have this one event, that kind of extended over the holidays with the fork.

which was BPO2. The PO2 went live, I believe it was the 7th UTC. And… yeah, generally, it went well. We have added more blobs to the protocol, so… At least for, the bulb layer, the DA layer, we are scaling, which is super cool. Anyone have anything they'd like to add to, their observations of BPO2?

Dustin Brody: I have a question, actually, relating to this, slash observation, which is that there was some discussion about, well, people were looking for a full 21 blocks, and eventually did find them, yes. But there was some question of… there were maybe… some reorgs people found, but I don't know if that they were looked at as whether they were statistically… unexpected, or were they out of the usual distribution, so to say? And also, was there a particular reason why the 21 bobs was sort of so difficult to find? Why people were seeing 19 and 20, but not 21?

Alex Stokes: Yeah, I'm not sure. Barnabas was there in the chat, they managed to hit multiple of these. So, I do know I was looking right around the fork, and there was an early block, that was orphaned. And some of us were looking into it. the latest I saw was just, actually it wasn't really so much the bobs with that particular block, but just that it was released pretty late into the slot, so… Yeah. It's definitely something we should be keeping an eye on. That being said, I haven't seen anything, that would suggest An issue here, with this 21 number? In general. There's just nothing else.

Barnabas Busa: Yeah, I just feel like there wasn't enough transactions to have multiple 21 blob blocks, especially during the holidays. The average blob transactions also went down significantly compared to before the holidays. So, Ed is just posting less blocked transactions, during the holidays. I… I'm expecting it to climb back up, eventually, though.

Alex Stokes: Yeah, makes sense. I mean, yeah, I mean, I think for me, the takeaway is we did this, and yeah, the protocol seems good. We certainly want to do more analysis around these higher blob counts, especially before we think about increasing them further for future BPOs. Any other comments on BPO2? Okay. Then, in that case, we'll move to Glamsterdam. So… Let's see here, a few things with Amsterdam. Yeah, maybe just to play things back, just as we're wrapping it back up from the holidays, so… Yeah, we essentially closed out, scoping for the fork. There are a number of CFI DIPs, along with the SFI DIP of EPBS right now.

And… yeah, that's, that's very good. Sets us up in a good place to keep moving forward with everything. So, yeah, that's basically where we're at right now. In terms of EIPs, there are a few updates today, and one thing, I suppose the EL wanted to get a temperature check, or… Yeah, so just a confirmation on this call. And that's with EAP8070. This is the sparse Blob Pull EIP. I think I might have missed exactly what the request was, but essentially, there was, I believe there was interest to CFI this on the EL side. They wanted to basically toss it back over to the CL side and say, hey, you know, just, by the way, any concerns, and if not, we'll go ahead and CFI it.

Odds are, yeah, maybe you can fill us in a bit more.

Ansgar Dietrichs: I mean, you basically already said it, it's, the CAP, the Spot pool, it's pretty overwhelmingly EL-side, but, there is at least some elements of it that also touch the CL, and so it just didn't feel right to just CFI it without at least some… having the CL in the loop, so really this is more of a… just in case they have any fundamental concerns about the CFP from the CR side, basically, please voice them, otherwise we would just continue moving this to CFI. So, yeah, really just a quick heads up, basically.

Alex Stokes: Okay, and to be clear, we should CFI this. And if someone… have the concern, they should voice it now. Otherwise, it will be CFI'd. As of this call. Okay, then let's CFI. Thank you, Oscar. Okay, two more updates to EIPs in Amsterdam. The first one here is from Etan. There's a question around the tree shape of how the stable containers feature is implemented. This, I think, is an update to EIP7688. There's a comment here that goes into more details, But that being said, let's see, is Itan on the call? It's probably better if you just give us an overview. Oh yeah, there you are.

Etan Kissling: I hope this time my mic works again.

Alex Stokes: I can hear you.

Etan Kissling: Traveling last.

Alex Stokes: It sounds good.

Etan Kissling: So yeah, the shape here, is based on a feedback that I received end of last year. If we switch to the right shape, there is an advantage that the later entries in an array are also more to the right in the tree, and that, can help with incremental tree construction a little bit. It's a very small change only in the library. EIP diff is literally this PR, it's just, like, swapping, the order of, how the hash is formed. And I just wanted to ask if everyone is okay here, or if anyone… has a strong opinion to not do that. Otherwise, I would just go ahead with this as the final spec change to this data structure.

Alex Stokes: Are there any concerns here with backwards compatibility, of Merklization of the other… you know, types or features in SOC? Or is this just contained to stable containers?

Etan Kissling: It's only for the new stuff. Okay. It's only, like, for the 7688. That's actually the other thing that… Like, I proposed merging it last month, and then I received feedback from POTUS that Justin was working on this big PR to make builders non-validators. I think that one has happened, so… I wonder whether, there are more blockers there, or, like, what's the… what's the timeline there? When should we go ahead with 768 and put it in?

Alex Stokes: Yeah, generally, you know, the process we try to follow is having one EIP at a time, so… We would want to get to, like, very stable dev nets with EPPBS, and then think about, sort of, promoting CFIDIPs to SFI. That being said, like, yeah, it has been CFI'd, and so, you know, now is the time to have the conversations we're having now. To iron out, you know, all these different details. And that being said, there are multiple questions here in the chat, just, yeah, hearing more about pros and cons. Miao, would you like to speak to that?

Etan Kissling: Yeah, the pro is… like, it's a very small, thing, obviously, like, the hash count is the same. And so on. The pro is, really like that when you create an incremental tree construction, similar to what we had back in the deposit contract snapshot, that you can sort of continuously collapse all the Trees as soon… like, you only have to track, like, a boundary that switches from left to right through the list, right? And you can continuously collapse what's on the left side, because new data is only added to the right of the tree. That's the advantage there. The downside is that it makes it… A tiny bit more complex to, think about. generalized indices, like, when you really have this low-level view of it. For example, making a multi-proof, it makes it a tiny bit more challenging to get it right, but…

I mean, it's really a small, cone and a small pro, like… We can also… not do it, and everything would also be fine. But given that we don't have any specs that use it yet, I think we should go ahead and just do it the more future-proof way. Streamable… It can be streamable. like… it depends how you make the protocol. Like, it's not made in that way. It also doesn't affect serialization, right? So, But, yeah, if you think about streamability, having the continuous data more closer together in the tree. is… is… is the slight pro that we get. But, like, the… it's only, like, the…

the number of hashes doesn't change, right? So… It's like just mirroring it.

Alex Stokes: Okay. I think in terms of moving forward, if there are no other questions at the moment, I would suggest we take feedback to the PR, that you linked here. Oh, this is to the IPs, let's see…

Etan Kissling: Yeah, like, maybe as a C channel, and if there is no opposition in a week, then I'll just go ahead, I think.

Alex Stokes: Yeah, that sounds reasonable. Okay, so yeah, jump into the SSG channel on the ETH R&D Discord if you want to discuss further. Thanks. Okay. Next up, POTUS had a proposal here to add some notion of when a node can detect censoring. And that then goes into… I think it was the fork choice. Yeah, Potos, would you like to say more?

Potuz: Sure. So I want to propose a change in the engine API, which is very much close to what we already have. So today, the EL, when we request a local payload, when we're about to propose, the EL has a Boolean that says. There's been censoring on the chain, you can use it however you want, but CLs can use this to take that block instead of the builder's block. So, what ePBS gives us is a better version of this, which is… when we send a new payload for validation to the engine, the engine replies with valid, syncing, accepted, whatever it is, and then also adds a Boolean that says, this block was censoring according to my view.

And then the CL can use this, because now the CL has information of who was the builder that built that block. And then the CL might use it to blacklist that builder, not request bids from them, blacklist it temporarily, whatever it is. So that will be up to clients to make it configurable by the operator. But the actual change that I'm requesting is to have this extra Boolean on the engine API on the call for new payload. most of the… of… of notify Nupelo. Most of the changes would have to be on the EL side. To make that decision and say this was censored or not. And… and these changes are mostly already worked out on clients because of the way of satisfying the inclusion list.

for FOCIL. So this would be mostly about, like, have they seen transactions that were in the mempool for long enough, and those transactions could have been included in this block, and they weren't included, and then the EL can say, this block was censoring or not, for example.

Alex Stokes: I feel like we've discussed a Boolean like this in the engine API in the past. I guess that's not currently in the engine API.

Potuz: I'm sorry, we discussed what?

Alex Stokes: a Boolean like this, I thought.

Potuz: It is. It is already, and it is implemented. It is implemented in Nethermind, and Prism already takes this into account. I think other clients already do this too. But this is implemented in the only way that we can do this now, which is in the call to get block, which is only the proposer that can actually make a local decision right there when they are proposing. This change is much more drastic in that I'm proposing to have this Boolean now in the call to notify new payload. This happens for every validator on every single block. So validators can keep track of which builders are censoring for every block, because now they have this visibility that before they didn't have.

Alex Stokes: I see, okay. Tony, your hands went up.

Toni Wahrstätter: Yeah, I'm not sure if this is a good idea, because today, how the mempool works, it's not standardized over clients. So, for example, we had, different transaction size limits over different clients. We also had different, minimum tips. that different clients had implemented, so… Notifying your payload is fully deterministic over different nodes today, and this would basically mean some dynamic info that is very much node-dependent, and even dependent on the configurations and flags you use, would suddenly become part of the response. So, yeah, I'm not sure if this is… if this is a good idea. For example, what could happen is that I would allow larger transactions for my node, because I run a certain client.

And then I would perceive every other block as being censoring, just because they don't include Those very large transactions. And also, as a builder, I would have no insight when I would be blacklisted. So it's very much, I would have to wait until the next registration of that validator, to even figure out that I was blacklisted.

Alex Stokes: Yeah. I mean, it's an interesting proposal. Are there any further comments right now, or questions? Otherwise, put us at ask where you'd want to continue the conversation.

Potuz: I think I'll propose the same thing on ACDE, because most of the changes would be on the engine, on the EL, and then after that, we can just… I mean, these discussions are being held now on the EPBS channel. I think that's… that's a good channel to continue.

Alex Stokes: Okay. Yeah, I at least want to think a bit more, and, you know, also with respect to what Tony said, you know, just all the different implications of doing this. Great. Thank you. Okay, I think that was everything for Glamsterdam. Any other points for Glamsterdam? If not, we'll move to Hegota. Okay. Great. So, like I said, we're in a pretty good place with scoping of Amsterdam, and then we introduce, the headliner process. To move forward with Hegota and Hegota. So… As a quick reminder. There's an overview of the process and the current timelines on this Ethan Magicians post.

Let me grab a link, it's there in the chat. And, essentially, we are moving forward with scoping Hegota. And to begin, we have headliner proposals. So, the way that this works, it's very similar to the headliner process we introduced with Amsterdam. Essentially, starting today, for about a month, we'd have a proposal period. So, the way this works, again, very similar to Glamsterdam, you should have a proposal post on these medications, tag it with this Hegota tag, and then bring this proposal to some ACD call, again, you know, pick the relevant layer. And yeah, then… The way it would work is, by having the post, and then also, you know, a… conversation, let's say, on ACD about it. That would be the formal proposal.

for that particular EIP as a hubliner. And this process will run for, again, like I said, about a month, then we'd move into discussion and selection for the headliner. So… We're just starting this process today, so I don't know if there'll be that much to talk about. That all being said, Yeah, following the process we kind of have laid out for Glamsterdam, there's this notion of fork focus, or the theme to the fork. I wanted just to, you know, sort of respect that part of the process, and if anyone would like to chime in around what they think the fork focus or theme should be, we can start that conversation today. Again, if you want to say something, let's keep it short.

I think ultimately, you know, this information is helpful, but yeah, I don't think we should get too caught up on exactly what the theme is. As again, I think most of us have a pretty clear idea of different AIPs we might want to move forward with for Hegota. So, would anyone like to say anything about, the theme, briefly? Sounds fair.

Ansgar Dietrichs: Yeah, maybe the only thing I wanted to say from more the EL side, I think sometimes there are hard folks where it naturally lines that EL and CL are focused on, like, things that have one integrated bigger theme to it. I think that is the case with Glamsterdam, for example. I think that could still happen with Hegota, we should be open to that, but I don't think there's any reason to, like, to be too adamant about trying to buy us a fork in that direction, and I, so far at least. don't think it's clear that that's where we will be going with Hegota. So I think, yeah, theme is maybe one of those things where, like, if it's not apparent that we naturally have it for a fork, it's fine to maybe just not overforce that as a lens.

Alex Stokes: Yeah. Makes sense to me. Okay, yeah, if anyone would like to add any more on this point, I would suggest going to this ETH Magicians post that I linked, and just adding a comment there. And otherwise, yeah, I think that was… most of what I had today, again, this is kind of more of an announcement that we're starting the process, just to be clear. Proposals have to be made before the 5th of February of this year. So, what that looks like, again, is like I was saying, where you need to have an ETH Medicions post up, and then also have presented it on an ACD call. And, the way this works is… the… Deadline here would be by, I think it's an ACDC on February 5th.

So, yeah. Again, you have a month, and… From there, we will keep the process moving. I think that's about all we should touch on today. Would anyone else like to add any comments or have any questions? Is that a theme, Marius? That you're… you would like to talk about? Or have in the… in the meta?

Marius van der Wijden: Mmm… It was more of maybe a topic that we can discuss. Because I feel like this is going to… Have a lot more focus in 2026, and since we Still have, like, an hour left, I think it would be… would be nice to talk a bit about seal hardening. I know there's been a lot of… Work done in the last year. And, I'm… I'm very curious to hear from consensus Layer clients how they feel about CL hardening, So that we don't get these… these kind of issues that we got on the… the testnets for Petra, and… and so on. So, I don't know, if we have time to talk about anything, I think CL hardening would be, like, a good topic to talk about.

Alex Stokes: Sure, yeah. Would anyone like to speak to that? Any client team? Bonus.

Potuz: perhaps not hardening per se, but, one thing we could coordinate, is into trying to schedule Demets For, something that some clients already have implemented, which is, starting checkpoint syncing from a non-finalized checkpoint. And trying to socially decide if we have a couple of finalized checkpoints, this is final, and we just go, or if we have known finalized checkpoints, but we're very fort, this is the final checkpoint, and we're just gonna decide that the network is this, meaning Socially recovering from an invalid finalized checkpoint is something that we haven't rehearsed. And we do not know how to do, and in particular, Prism hasn't even implemented this. So we could, at least set a timeline, or… Or… or start focusing on how to implement and how to test this.

Alex Stokes: Yeah, you mentioned, like, multiple finalized checkpoints. Is that the scenario, or is it an invalid finalized checkpoint, a singular one?

Potuz: So… most… I mean, the two most important ones would be no finalization, and we're for it. And the other one is, we have finalized an invalid checkpoint, something like what happened already in a testnet. And… and we cannot recover from that. So, in finalizing an invalid checkpoint and not finalizing at all, and we need to just choose one branch. Otherwise, we're gonna go into, like, inactivity leaks, and then split, eventually, the chain.

Alex Stokes: Yeah, I mean, if we did finalize an invalid checkpoint, we'd have to manually recover from that. Presumably some flag that says, hey, you know, when I go process the network, ignore this, even though you see it as finalized. That's been implemented. Okay.

Potuz: That's been implemented on every client, like, blacklisting blocks, it's been implemented on every client, but if we go back to the situation in which we had on testnet, that we would slash a bunch of clients because of a bug. Because they would surround themselves… I mean, we had a bunch of clients that were deadlocked in that situation. This requires social interaction, and then even just continuing on the other branch, which was valid. We just don't know how to do this today, so finding a solution for that would be nice.

Alex Stokes: I agree. I also don't know if, the people here today are prepared. To get into this much further. But yeah, that is… That is a good point. This is one thing to be, you know, very concerned about. this is kind of, I think, a pretty extreme scenario. I imagine Marius also had a less extreme scenario than mine, just around… You know, how… how clients are. resilient just to different things on the network, even before, yeah, bad finalization, just various, you know, DOS vectors, or, yeah, syncing and non-finality and different scenarios like this.

Marius van der Wijden: Yeah, exactly. I don't know, like, when I talked to CR… unfortunately, we didn't have a good time in the last couple of months to have, like. like, these bigger group discussions between EL and CL. But when we talked in Berlin, it was, like, one of the major, through-lines was that the CL teams feel kind of rushed, and they would like to They would like to focus more on security, they would like to focus more on hardening, they would like to focus more on… On… on… yeah. Exercising these code paths, and… I… I'm just wondering how much of that has… Already happened, and… if… I don't know, it doesn't seem to me to be that big of a problem if no one is… no one feels like speaking up on the call about it. But I…

Yeah, maybe technical depth. Yeah, I'm just wondering what the current thinking is on all of these topics right now.

Alex Stokes: I know we all have a lot of calls, but we could have a formal breakout for this. That might be a nice way to move forward. Any other client team want to speak to us?

Saulius Grigaitis: Hmm.

Alex Stokes: Otherwise, I'm not sure there's more to say today.

Saulius Grigaitis: I just wanted to say that it… I mean, the… the recent… Goals or vision is to have, like, a two-hot works per year, and this is, like, a… a different direction of what Myris is saying, and I don't think that there is that much time and focus left after the actual features development to focus a lot on technical depth, cleanups, you know, security stuff, and so on. So… Yeah, I think this is, at least for the small teams, this could be, one of the reasons why it's, it's really hard to find the time to, to do something else apart from building, new, new features, and, And just catching up with, with,

With the development, in terms of the features.

Alex Stokes: Yeah, I mean, there's certainly the trade-offs there that we're all very keenly aware of. You know, tying this back. I just thought someone said something.

Matthew Keil: I wanted to dovetail in the discussion about, pushing the BPOs, looking at blob consumption, you know, they're not necessarily necessary at this particular moment, and they're relatively easy to turn on. But not having that hang over our heads of, like, make sure you're watching your notes, make sure things are not happening, you know, that also kind of plays into that pressure that, that takes away from our focus of being able to develop the features and do other cleanup.

Alex Stokes: Alright, yeah, so again, there is a trade-off here. tying this back more through today's agenda, with Hegota scoping, you know, one… one way to square these two is, as we move forward with scoping, just keeping this in mind, and then having, you know, Hegota be a lighter fork. Because then there's, you know, less pressure to develop new features, because there are simply fewer of them. And there's more time for all these other things we've been discussing. Okay. Any other comments on this? Morris is asking how people feel about EPBS security. what I would say myself is, again, we have good testing,

For the state transition and things like that. There are fork choice changes to EVBS, which are… Yeah, more interesting. Miguel?

Mikhail Kalinin: Yeah, probably can add on that, If we fall, remember we have, We have this FOC Choice compliance test ensued that… is not… I… to my knowledge, is not integrated into any client except for Taku. That far, and, we… we are planning to apply To actually, catch up with the EPBS changes and introduce them into this test institute. And, from the developer's perspective, it means that, Developers will have to. kind of adopt this testing suit. I don't know how much of Of time and efforts, and engineering efforts it will require, from the development perspective. Obviously, depends on the client, and yeah, fine design. But this is something that, should, Help a lot with testing the fork choice changes.

So, yeah, that's just, you know, from the test in front, and from the… yeah, in the application to EPBS.

Alex Stokes: Yeah, that's a good part. Given the change of the PBS, this is, probably a very good time to double down on that set of tests.

Potuz: So… eBBS has been on the discussion for… until, like, not long ago, on whether or not we would have certain features, like trustless payments and so. And then we decided at the very last minute to make a rather big change, which is not making the builders validators. And we already know that there's some bugs there. We already know that there's some bugs at the protocol level on how to handle deposits, for example. Which is kind of natural, the PR just merged last week. So… Yeah, so we expect to continue finding this kind of bugs for a while, until we actually do go into interrupt.

Mikhail Kalinin: By the way, yes, I didn't mention that we're also, kind of aiming to… to use model-based, model-based testing that we use for the FOC Choice stuff, also for the stage position, For the EPBS scope. For the whole APBS scope. So we'll just, you know, give it a try.

Alex Stokes: Yeah, I think these are all good things to have on our minds as we move forward into the new year. And we think about Glamsterdam and Hegota. Any other comments today? Okay. If not, anything else that was not on the agenda? If not, I think we wrap up early. And… Happy to be here, everyone.

Potuz: Happy New Year.

Alex Stokes: Okay, yep, let's wrap in. Bye, everyone.

Mikhail Kalinin: Mine.

Ansgar Dietrichs: Bye-bye. Happy New Year.

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