AllCoreDevs - Consensus #172

|2026-01-08| Agenda: #1844| canonical JSON

Transcript

stokes:Happy New Year, everyone! This is the first ACDC of 2026. It is call 172.

stokes:Let me grab a link to the agenda, I'll put it here in the chat.

stokes:So, yeah, today, a couple things to cover, a few quick announcements, then we'll touch on Fusaka, Glamsterdam, and Hegota. So…

stokes:Let's get into it.

stokes:I put these announcements first, because I think they should be pretty brief.

stokes:The first one is just a shout-out for a breakout on the task confirmation rule.

stokes:Let's see, is either Roberto or Mikael here to say something about that?

Mikhail Kalinin:Hey, I'm here. Happy New Year, everyone.

Mikhail Kalinin:So… There is a fast confirmation rule, there is a PR that is open to the spec.

Mikhail Kalinin:And, we actually plan to… to have a…

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

Mikhail Kalinin:Where we can discuss the progress, the challenges that developers see in implementing the algorithm, also incorporate feedback into this fact.

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

Mikhail Kalinin:In the meantime, we… it's a bit of an update, from…

Mikhail Kalinin:the spec and spec development side and testing side. We work on tests currently, so the spec is,

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

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

Mikhail Kalinin:By the beginning of February, by the end of January, Some kind of that.

Mikhail Kalinin:So this is our main priority now on this fast confirmation thing.

Mikhail Kalinin:Yeah, that's… that's probably it.

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

Will Corcoran:tuesday, January… I forget, the 20th, I believe? It's at 2 p.m. UTC, and yeah, we'll…

Will Corcoran:We'll be running every other week.

stokes:Okay, sounds good. Thank you both for the update.

stokes:So, yeah, very exciting work there. If you're interested to dig in deeper, join the breakout.

stokes:Okay, next, I don't know if Nixa's here, but she had a comment,

stokes:she actually worked at the PR, but I guess she and some others have been working on, refining this notion of champion.

stokes:It's a document in the PM repo, I'll just grab a link to the PR here.

stokes:And I think, for now, it's essentially a request for comments.

stokes:So, take a look at that if you would like to contribute there.

stokes:Okay, so I think those were all the announcements we had, and yeah, let's then turn to Fusaka. So…

stokes:We did have this one event, that kind of extended over the holidays with the fork.

stokes:which was BPO2.

stokes:The PO2 went live, I believe it was the 7th UTC.

stokes:And… yeah, generally, it went well. We have added more blobs to the protocol, so…

stokes:At least for, the bulb layer, the DA layer, we are scaling, which is super cool.

stokes:Anyone have anything they'd like to add to, their observations of BPO2?

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

Dustin:But there was some question of… there were maybe…

Dustin:some reorgs people found, but I don't know if that they were looked at as whether they were statistically…

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

stokes:Yeah, I'm not sure. Barnabas was there in the chat, they managed to hit multiple of these.

stokes:So, I do know I was looking right around the fork, and there was an early block, that was orphaned.

stokes:And some of us were looking into it.

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

stokes:Yeah.

stokes:It's definitely something we should be keeping an eye on. That being said, I haven't seen anything, that would suggest

stokes:An issue here, with this 21 number?

stokes:In general.

stokes:There's just nothing else.

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

Barnabas:So, Ed is just posting less blocked transactions, during the holidays.

Barnabas:I… I'm expecting it to climb back up, eventually, though.

stokes:Yeah, makes sense.

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

stokes:Any other comments on BPO2?

stokes:Okay.

stokes:Then, in that case, we'll move to Glamsterdam. So…

stokes:Let's see here, a few things with Amsterdam.

stokes:Yeah, maybe just to play things back, just as we're wrapping it back up from the holidays, so…

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

stokes:And… yeah, that's, that's very good. Sets us up in a good place to keep moving forward with everything.

stokes:So, yeah, that's basically where we're at right now.

stokes:In terms of EIPs, there are a few updates today, and one thing, I suppose the EL wanted to get a temperature check, or…

stokes:Yeah, so just a confirmation on this call.

stokes:And that's with EAP8070. This is the sparse Blob Pull EIP.

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

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

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

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

stokes:Okay, and to be clear, we should CFI this.

stokes:And if someone… have the concern, they should voice it now. Otherwise, it will be CFI'd.

stokes:As of this call.

stokes:Okay, then let's CFI.

stokes:Thank you, Oscar.

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

stokes:This, I think, is an update to EIP7688.

stokes:There's a comment here that goes into more details,

stokes: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 (Nimbus):I hope this time my mic works again.

stokes:I can hear you.

Etan (Nimbus):Traveling last.

stokes:It sounds good.

Etan (Nimbus):So yeah, the shape here, is based on a feedback that I received end of last year.

Etan (Nimbus):If we switch to the right shape, there is an advantage that the later entries in an array

Etan (Nimbus):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.

Etan (Nimbus):EIP diff is literally this PR, it's just, like, swapping,

Etan (Nimbus):the order of, how the hash is formed. And I just wanted to ask if everyone is okay here, or if anyone…

Etan (Nimbus):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.

stokes:Are there any concerns here with backwards compatibility, of Merklization of the other…

stokes:you know, types or features in SOC?

stokes:Or is this just contained to stable containers?

Etan (Nimbus):It's only for the new stuff. Okay. It's only, like, for the 7688. That's actually the other thing that…

Etan (Nimbus):Like,

Etan (Nimbus):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…

Etan (Nimbus):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?

stokes:Yeah, generally, you know, the process we try to follow is having one EIP at a time, so…

stokes:We would want to get to, like, very stable dev nets with EPPBS, and then think about, sort of, promoting CFIDIPs to SFI.

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

stokes:To iron out, you know, all these different details.

stokes:And that being said, there are multiple questions here in the chat, just, yeah, hearing more about pros and cons.

stokes:Miao, would you like to speak to that?

Etan (Nimbus):Yeah, the pro is… like, it's a very small, thing, obviously, like, the hash count is the same.

Etan (Nimbus):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

Etan (Nimbus):Trees as soon… like, you only have to track, like, a boundary that switches from left to right through the list, right?

Etan (Nimbus):And you can continuously collapse what's on the left side, because new data is only added to the right of the tree.

Etan (Nimbus):That's the advantage there. The downside is that it makes it…

Etan (Nimbus):A tiny bit more complex to, think about.

Etan (Nimbus):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…

Etan (Nimbus):I mean, it's really a small, cone and a small pro, like… We can also…

Etan (Nimbus):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.

Etan (Nimbus):Streamable… It can be streamable.

Etan (Nimbus):like…

Etan (Nimbus):it depends how you make the protocol. Like, it's not made in that way. It also doesn't affect serialization, right? So,

Etan (Nimbus):But, yeah, if you think about streamability, having the continuous data more closer together in the tree.

Etan (Nimbus):is… is… is the slight pro that we get. But, like, the… it's only, like, the…

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

stokes:Okay.

stokes:I think in terms of moving forward, if there are no other questions at the moment,

stokes:I would suggest we take feedback to the PR, that you linked here.

stokes:Oh, this is to the IPs, let's see…

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

stokes:Yeah, that sounds reasonable.

stokes:Okay, so yeah, jump into the SSG channel on the ETH R&D Discord if you want to discuss further.

stokes:Thanks.

stokes:Okay. Next up, POTUS had a proposal here to add some notion of when a node can detect censoring.

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

Potuz:So today, the EL, when we request a local payload, when we're about to propose, the EL has a Boolean that says.

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

Potuz:So, what ePBS gives us is a better version of this, which is…

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

Potuz:And then the CL can use this, because now the CL has information of who was the builder that built that block.

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

Potuz:But the actual change that I'm requesting is to have this extra Boolean on the engine API on the call for new payload.

Potuz:most of the… of… of notify Nupelo. Most of the changes

Potuz:would have to be on the EL side.

Potuz:To make that decision and say this was censored or not.

Potuz:And… and these changes are mostly already worked out on clients because of the way of satisfying the inclusion list.

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

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?

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.

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

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

stokes:I see, okay.

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

Toni Wahrstätter:that different clients had implemented, so…

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

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

Toni Wahrstätter:And then I would perceive every other block as being censoring, just because they don't include

Toni Wahrstätter:Those very large transactions.

Toni Wahrstätter:And also, as a builder, I would have no insight when I would be blacklisted.

Toni Wahrstätter:So it's very much, I would have to wait until

Toni Wahrstätter:the next registration of that validator, to even figure out that I was blacklisted.

stokes:Yeah.

stokes:I mean, it's an interesting proposal.

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

Potuz:I think that's… that's a good channel to continue.

stokes:Okay.

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

stokes:Great. Thank you.

stokes:Okay, I think that was everything for Glamsterdam. Any other points for Glamsterdam?

stokes:If not, we'll move to Hegota.

stokes:Okay.

stokes:Great. So, like I said, we're in a pretty good place with scoping of Amsterdam, and then we introduce, the headliner process.

stokes:To move forward with Hegota and Hegota. So… As a quick reminder.

stokes:There's an overview of the process and the current timelines on this Ethan Magicians post.

stokes:Let me grab a link, it's there in the chat.

stokes:And, essentially, we are moving forward with scoping Hegota.

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

stokes:Essentially, starting today, for about a month, we'd have a proposal period.

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

stokes:And yeah, then…

stokes:The way it would work is, by having the post, and then also, you know, a…

stokes:conversation, let's say, on ACD about it. That would be the formal proposal.

stokes:for that particular EIP as a hubliner.

stokes:And this process will run for, again, like I said, about a month, then we'd move into discussion and selection for the headliner.

stokes:So…

stokes:We're just starting this process today, so I don't know if there'll be that much to talk about.

stokes:That all being said,

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

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

stokes:Again, if you want to say something, let's keep it short.

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

stokes:As again, I think most of us have a pretty clear idea of

stokes:different AIPs we might want to move forward with for Hegota.

stokes:So, would anyone like to say anything about, the theme, briefly?

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

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

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

stokes:Yeah.

stokes:Makes sense to me.

stokes:Okay, yeah, if anyone would like to add any more on this point,

stokes:I would suggest going to this ETH Magicians post that I linked, and just adding a comment there.

stokes:And otherwise, yeah, I think that was…

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

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

stokes:And, the way this works is… the…

stokes:Deadline here would be by, I think it's an ACDC on February 5th.

stokes:So, yeah. Again, you have a month, and…

stokes:From there, we will keep the process moving.

stokes:I think that's about all we should touch on today. Would anyone else like to add any comments or have any questions?

stokes:Is that a theme, Marius?

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

Marius van der Wijden:Because I feel like this is going to…

Marius van der Wijden:Have a lot more focus in 2026, and since we

Marius van der Wijden:Still have, like, an hour left,

Marius van der Wijden:I think it would be… would be nice to talk a bit about seal hardening.

Marius van der Wijden:I know there's been a lot of…

Marius van der Wijden:Work done in the last year.

Marius van der Wijden:And, I'm… I'm very curious to hear from consensus Layer clients how they feel about CL hardening,

Marius van der Wijden:So that we don't get these… these kind of issues that we got on the… the testnets for Petra, and… and so on.

Marius van der Wijden: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.

stokes:Sure, yeah. Would anyone like to speak to that?

stokes:Any client team?

stokes:Bonus.

Potuz:perhaps not hardening per se, but, one thing we could coordinate, is into trying to schedule Demets

Potuz:For, something that some clients already have implemented, which is, starting checkpoint syncing from a non-finalized checkpoint.

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

Potuz:Socially recovering from an invalid finalized checkpoint is something that we haven't rehearsed.

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

Potuz:Or… or start focusing on how to implement and how to test this.

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.

Potuz:And the other one is, we have finalized an invalid checkpoint, something like what happened already in a testnet.

Potuz:And… and we cannot recover from that.

Potuz:So, in finalizing an invalid checkpoint and not finalizing at all, and we need to just choose one branch.

Potuz:Otherwise, we're gonna go into, like, inactivity leaks, and then split, eventually, the chain.

stokes:Yeah, I mean, if we did finalize an invalid checkpoint, we'd have to manually recover from that.

stokes:Presumably some flag that says, hey, you know, when I go process the network, ignore this, even though you see it as finalized.

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

Potuz:Because they would surround themselves… I mean, we had a bunch of clients that were deadlocked in that situation.

Potuz:This requires social interaction, and then even just continuing on the other branch, which was valid.

Potuz:We just don't know how to do this today, so finding a solution for that would be nice.

stokes:I agree.

stokes:I also don't know if, the people here today are prepared.

stokes:To get into this much further.

stokes:But yeah, that is… That is a good point.

stokes:This is one thing to be, you know, very concerned about.

stokes:this is kind of, I think, a pretty extreme scenario. I imagine Marius also had a less extreme scenario than mine, just around…

stokes:You know, how… how clients are.

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

Marius van der Wijden: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

Marius van der Wijden:They would like to focus more on security, they would like to focus more on hardening, they would like to focus more on…

Marius van der Wijden:On… on… yeah.

Marius van der Wijden:Exercising these code paths, and…

Marius van der Wijden:I… I'm just wondering how much of that has… Already happened, and…

Marius van der Wijden: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…

Marius van der Wijden:Yeah, maybe technical depth.

Marius van der Wijden:Yeah, I'm just wondering what the current thinking is on all of these topics right now.

stokes:I know we all have a lot of calls, but we could have a formal breakout for this.

stokes:That might be a nice way to move forward.

stokes:Any other client team want to speak to us?

saulius:Hmm.

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

saulius:I just wanted to say that it… I mean, the… the recent…

saulius:Goals or vision is to have, like, a two-hot works per year, and this is, like, a…

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

saulius:cleanups, you know, security stuff, and so on. So…

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

saulius:And just catching up with, with,

saulius:With the development, in terms of the features.

stokes:Yeah, I mean, there's certainly the trade-offs there that we're all very keenly aware of.

stokes:You know, tying this back.

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

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

stokes:Alright, yeah, so again, there is a trade-off here.

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

stokes:Because then there's, you know, less pressure to develop new features, because there are simply fewer of them.

stokes:And there's more time for all these other things we've been discussing.

stokes:Okay.

stokes:Any other comments on this?

stokes:Morris is asking how people feel about EPBS security.

stokes:what I would say myself is, again, we have good testing,

stokes:For the state transition and things like that.

stokes:There are fork choice changes to EVBS, which are… Yeah, more interesting.

stokes:Miguel?

Mikhail Kalinin:Yeah, probably can add on that,

Mikhail Kalinin:If we fall, remember we have,

Mikhail Kalinin:We have this FOC Choice compliance test ensued that…

Mikhail Kalinin:is not… I… to my knowledge, is not integrated into any client except for Taku.

Mikhail Kalinin:That far, and, we… we are planning to apply To actually,

Mikhail Kalinin:catch up with the EPBS changes and introduce them into this test institute.

Mikhail Kalinin:And, from the developer's perspective, it means that, Developers will have to.

Mikhail Kalinin:kind of adopt this testing suit. I don't know how much of

Mikhail Kalinin:Of time and efforts, and engineering efforts it will require, from the development perspective.

Mikhail Kalinin:Obviously, depends on the client, and yeah, fine design.

Mikhail Kalinin:But this is something that, should,

Mikhail Kalinin:Help a lot with testing the fork choice changes.

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

stokes:Yeah, that's a good part.

stokes:Given the change of the PBS, this is, probably a very good time to double down on that set of tests.

Potuz:So…

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

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

Potuz:Which is kind of natural, the PR just merged last week.

Potuz:So…

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

Mikhail Kalinin:to use model-based, model-based testing that we use for the FOC Choice stuff, also for the stage position,

Mikhail Kalinin:For the EPBS scope. For the whole APBS scope.

Mikhail Kalinin:So we'll just, you know, give it a try.

stokes:Yeah, I think these are all good things to have on our minds as we move forward into the new year.

stokes:And we think about Glamsterdam and Hegota.

stokes:Any other comments today?

stokes:Okay.

stokes:If not, anything else that was not on the agenda?

stokes:If not, I think we wrap up early.

stokes:And… Happy to be here, everyone.

Potuz:Happy New Year.

stokes:Okay, yep, let's wrap in.

stokes:Bye, everyone.

Mikhail Kalinin:Mine.

Ansgar Dietrichs:Bye-bye. Happy New Year.

Chat Logs

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

Trent:Can anyone share the stream link for Preston in the discord?

Justin Florentine (Besu):https://youtube.com/watch?v=ZXxk3cV7Tjw

Mikhail Kalinin:https://github.com/ethereum/consensus-specs/pull/4747

Trent:Replying to "https://youtube.com/..." Yes, clicked that and it’s unavailable

Josh Davis:Replying to "https://youtube.com/..." I shared it

Trent:Replying to "https://youtube.com/..." thanks!

Will Corcoran:We also have a fancy website coming together ;)

stokes:https://github.com/ethereum/pm/pull/1864

nixo:Replying to "https://github.com/e..." tl;dr: champions were somewhat unclear this glam round what was required to get an EIP moving forward or unclear on deadlines for progress, so trying to create more clarity around that

Ben Adams:Replying to "https://youtube.com/..." Still says unavailable?

Barnabas:we managed to hit multiple 21 blob blocks.

Josh Davis:Replying to "https://youtube.com/..." https://www.youtube.com/live/9JQ7OorDgCE

Dima Gusakov | Lido:Do we have data on real demand vs artificial pumps from panda ops?

Barnabas:we only pumped a little bit yesterday, 4-5 slots to hit 21 blobs

Justin Traglia:When next BPOs?

Toni Wahrstätter:Now with peerDAS, reorgs become a more important metric than missed head votes

Leo:we should not rush to higher BPOs if there is no demand for it in the coming weeks/months

Trent:Replying to "Do we have data on r..." Their addresses are tagged in hildobby’s dune db, easy to filter out if you want https://dune.com/hildobby/blobs

stokes:https://github.com/ethereum/pm/issues/1844#issuecomment-3715952155

Dima Gusakov | Lido:Replying to "we should not rush t..." As I see from here -https://blobscan.com/stats there is no increase in the daily blob counts after Fusaka

Etan (Nimbus):https://github.com/ethereum/EIPs/pull/11032/files

Justin Traglia:What are the pros/cons?

Dima Gusakov | Lido:Also want to see a clear pros for the proposed option

Trent:Replying to "we should not rush t..." Moderation in everything, including moderation =) As pointed out in past instances of this discussion - it’s important to prepare for future growth of existing blob users, and future users who need certainty that we will be able to accommodate their needs. Worth keeping in mind

Marius van der Wijden:SSZ is not streameable anyway, right?

Leo:Replying to "we should not rush..." https://www.migalabs.io/blobs The number of daily blobs seems to be actually decreasing, so clearly not enough demand.

Etan (Nimbus):#ssz channel in discord

Barnabas:censor the censoroor

Dima Gusakov | Lido:Replying to "we should not rush t..." Given that we already had 2 BPOs I agree with Leo that without observed increase in demand we should not rush with increase

Matthew Keil:Replying to "we should not rush t..." +1

Marius van der Wijden:Its not super easy to implement this on the el it would require a lot of additional work (screening the blocks for transactions in the txpool)

Potuz:You already have to do this to produce an IL for focil

stokes:https://ethereum-magicians.org/t/eip-8081-hegota-network-upgrade-meta-thread/26876

Potuz:It would be the same as checking IL satisfaction essentially

Barnabas:wouldn’t it make more sense to bundle it with IL changes and not overload Glammy?

Potuz:Replying to "wouldn’t it make mor..." This is completely optional, clients can just return always “no”

Potuz:Replying to "wouldn’t it make mor..." It’s not consensus breaking and not fork choice decision is being made

Marc:Replying to "wouldn’t it make mor…" is it more of a makeshift until we have focil or you think it would be useful afterwards?

Jihoon:IL satisfaction check is deterministic and not heuristics.

Potuz:Replying to "wouldn’t it make mor..." So for an EL to implement this is simply adding a boolean that always says “no"

Trent:Replying to "we should not rush t..." Not saying it needs to be rushed - just boosting context from past discussions as to why centering on current demand may miss important considerations

Potuz:Replying to "It would be the same..." It’s irrelevant for what I am requesting though

Ansgar Dietrichs:it’s fine to have a bit of a discussion on themes today already, but I think we should mostly wait until we have all the headliner proposals

Potuz:Replying to "wouldn’t it make mor..." It’s a makeshift

Dima Gusakov | Lido:Sorry for the dumb Q, but what is the good time for the non-headliner proposals?

Toni Wahrstätter:Replying to "wouldn’t it make mor..." using such a locally-available-info mechanism for focil is fine but not for blacklisting builders as mempools aren't standardized.

Potuz:Replying to "wouldn’t it make mor..." I disagree, the CL can track that a particular builder is actually censoring 100% of blocks, and others arent

Łukasz Rozmej:theme: technical debt

Potuz:Replying to "wouldn’t it make mor..." And then decide then, with actual statistical information

Marius van der Wijden:I think the theme for glamsterdam was scale, I don't think that needs to be the main focus for hegota

nixo:Replying to "Sorry for the dumb Q..." it’s in the ethmag link above - it’ll follow the headliner proposals

Jihoon:Replying to "It would be the same..." I also don't think it is right to say that ELs already have good heuristics for IL production. They will have to devise and implement their strategies.

Barnabas:Replying to "theme: technical deb..." marketing department does not approve this message.

Dima Gusakov | Lido:Replying to "Sorry for the dumb Q..." Got you. So it is late Feb early March

Dima Gusakov | Lido:Replying to "Sorry for the dumb Q..." Thanks!

Potuz:Replying to "It would be the same..." They can just say “this block is not censoring” and that’s fine

Potuz:Replying to "It would be the same..." That’s a very simple heuristic

Ansgar Dietrichs:damn I am very envious of ACDC regarding call agenda size…

Marius van der Wijden:CL hardening?

Barnabas:Can we start proposing headliners, as we have 1 whole hour left?

Jihoon:Replying to "It would be the same..." What happens when clients produce different output?

stokes:Replying to "Can we start proposi..." Fine w/ an early discussion

stokes:Replying to "Can we start proposi..." Not sure champions are ready today to formally get into it

Toni Wahrstätter:Replying to "wouldn’t it make mor..." the problem is that the EL cannot really tell. Everyone can come up with their own heursistics but noone is right

Toni Wahrstätter:Replying to "wouldn’t it make mor..." So, the resp you get as a CL from different ELs is different over ELs.

Potuz:Replying to "wouldn’t it make mor..." That’s a good feature not a bug

Potuz:100% of what Marius is saying

Potuz:Can’t stress this enough

Matthew Keil:Agreed

Matthew Keil:And Technical Debt is a big part of this hardening…

Toni Wahrstätter:Replying to "wouldn’t it make mor..." If one EL has a higher tx size limit than the others than validators using this EL would blacklist all builders

Toni Wahrstätter:Replying to "wouldn’t it make mor..." It's a feature for focil, but not for blacklisting. We would have more accidential blacklisting events (without knowing that one happened) than real ones

Potuz:Replying to "wouldn’t it make mor..." Again, statistical inference works. If that node operator wants to blacklist every builder that doesn’t include large txs that’s a feature

Potuz:Replying to "wouldn’t it make mor..." They can do so anyway

Toni Wahrstätter:Replying to "wouldn’t it make mor..." Not being included also depends on being able to pay the basefee. ELs would not only need to track the time until inclusion but also for how long the tx has actually been able to pay the basefee

Jihoon:Replying to "wouldn’t it make mor..." I also think it is better to not try to overload more feature to Glamsterdam especially if it's a makeshift.

Barnabas:security of the chain should always be on a higher priority than new features.

Potuz:Replying to "wouldn’t it make mor..." This is kinda ridiculous, there’s no overloading, they can just say “this block is not censoring” and that’s it. Exactly what happened with the already existing boolean. And then Nethermind implemented it when they had time

Potuz:Replying to "wouldn’t it make mor..." It’s not affecting fork choice, nor attesting, nor proposing

Potuz:Replying to "wouldn’t it make mor..." It’s not consensus breaking, it’s just an optional boolean in the engine

Toni Wahrstätter:Replying to "wouldn’t it make mor..." the mempool is a non-standarized space and we would certainly open this up to attack other builders, trying to get them blacklisted

Marius van der Wijden:How do client teams feel about epbs security?

Potuz:Scared as shit

Jihoon:Replying to "wouldn’t it make mor..." It is an extra work, whether you call it overload or not.

stokes:2026 is an important year, lots to do ;)

Justin Traglia:Here’s a link to what Mikhail is talking about: https://github.com/ethereum/consensus-specs/tree/master/tests/generators/compliance_runners/fork_choice

Potuz:Nice Mikhail! Would be nice to have time to actually implement this. EPF could be useful for this if one is reading

Justin Traglia:Happy new year, bye everyone

Mikhail Kalinin:Replying to "Nice Mikhail! Would ..." i hope that since this is the current hard fork devs are working on they will find a time to implement testing suites devfeloped for that features

Summary

9 highlights · 1 decisions · 4 action itemsExperimental

fork status and schedule

BPO2 live Jan 7th; multiple 21-blob blocks achieved00:08:12
Blob demand low over holidays; early orphan due to late release, not blobs00:10:28
Glamsterdam scoping closed; ePBS SFI with multiple CFI EIPs00:11:43

testing progress

Fast confirmation rule spec ready; tests expected late Jan00:05:18
Fork choice compliance tests only in Teku; will add ePBS coverage00:40:25
Model-based testing planned for ePBS state transition00:42:39

client updates

ePBS non-validator builders PR merged; deposit bugs being fixed00:42:02
CL recovery rehearsals needed00:31:58

organizational

No forced theme for Hegota; EL/CL may diverge00:28:04

Decisions

EIP-8070 moved to CFI for Glamsterdam00:13:29

Action Items

CL devs: Review stable containers tree shape PR in #ssz within 1 week00:19:13
Potuz: Propose censoring detection Boolean on ACDE00:24:31
EIP champions: Hegota headliner proposals open; requires EthMagicians post + ACD presentation00:25:46
CL clients: Integrate fork choice compliance tests; add ePBS coverage00:40:57

Targets

Jan 20 - Fast confirmation breakouts begin (bi-weekly, 2pm UTC)00:06:59
Late Jan - Fast confirmation rule tests ready00:06:27
Feb 5 (ACDC) - Hegota headliner proposal deadline00:29:30
Early March - Production-ready fast confirmation implementations00:05:20