ePBS Breakout #29

Transcript

Justin Traglia: Good morning, everyone. Let's just give it a few more minutes before getting started. One more minute, and then we'll get started.

Okay, Akash, could you start the stream, please?

Akash | ECH: Yeah, we are live.

Justin Traglia: Thank you. Hello, everyone. Welcome to EPBS Breakout Call 29. This is the final breakout call for ePBS. After which, starting in 2026, EPBS discussions will take place at ACDT. Yeah. Let's just get right into maybe updates from client teams. Is anyone from… here from PRISM that could give us an update?

Terence Tsao: Not much. We're just waiting for the PR for the, state builder to be merged, so we continue making progress. I'm implementing part of it, the business state. And, the… and the SSD status structure. So, yeah, so I'm just waiting for the PR to merge, and hopefully we can get the release, and after the release, I can merge the PR, which should unblock the rest of the progress.

Justin Traglia: Awesome, yeah. And, did you have an opportunity to check the reference tests?

Terence Tsao: I have not. It's much… it's much harder to do that versus just having, like, an official release, so I think I would just wait for an official release, and the… and the… also, no rush on that as well.

Justin Traglia: Okay. And, I guess we could plan on making a new release pretty much as soon as we get, like, this group of PRs merged. So maybe next week?

Terence Tsao: Sounds fair.

Justin Traglia: Okay, thanks. Is there anyone here from Lighthouse that can give us an update? If any update? Shane Moore just joined. Shane, are you from Lighthouse? Could you give us an update?

Shane Moore: Hey! Hey guys. Yeah, on the Lighthouse side, we just, merged the containers branch into our Unstable, so pretty, good milestone there. Then, I think Michael and Manas have actually just started taking a look at the fork choice-related changes, which is nice. Mark is still, handling some, like, payload separation-type changes, and I'm tackling, payload attestations.

Justin Traglia: Awesome. And that is a good milestone. Congrats.

Shane Moore: Thank you, thank you.

Justin Traglia: Okay. Anyone from TechQu here? I see a couple.

Enrico Del Fante: Yeah, not that much. Updates. This week has been… Along with Raz, Stephanie is off, and yeah, the only… the last thing we were working on… actually, Mehdi was working on it. Still related to, gossip validation rules that needs to be… Redesigned a little bit to make it a better cross-fork. Aware… And, yeah, not that much progress still on that, so I don't know if Meli wants to add anything. Probably.

Mehdi Aouadi: No, that's basically it, yeah, I've been working on the Gossip player, so, yeah.

Enrico Del Fante: So, yeah, that's it.

Justin Traglia: Okay, and Stefan's been on vacation, right?

Enrico Del Fante: Yeah, it is, yeah, I think Lee will be back next year. And most of us will be starting… Going off from… from today, so… Yep.

Justin Traglia: Expected. Same for me. Okay, thank you for the update. Is there anyone here from Nembos that can give us an update? I don't think anyone from members sits here. Okay. Lodestar?

NC: From Lostar's side, we got, concept topic, concert validation. We got the opt for… Seen cash, done. And I'm… I'm personally looking at, data column sidecar and how to make that change, and also the block import, flow.

Justin Traglia: I'm sorry, the blocking portfolio? What is that?

NC: Yes. So, basically, Yeah, just basically, instead of just importing, like, a single block, you import the consensus block. And then you have, like, this intermediate beacon state that we need to store somewhere. And then you have the execution payload, come in, and do the remaining of the state transition.

Justin Traglia: I… okay, I misunderstood. Thank you, that makes sense now. Okay, thanks. That's been help.

Caleb: Oh, hi, sir. Yeah, sorry, from Limbus. I missed that, sir.

Justin Traglia: August. Sorry, August, you can give an update now if you want to.

Caleb: Yeah, so we've been working on integrating the payload attestations to the validator duties, basically. Then, on the one hand, we are waiting for the new spec release. And also, we have somebody working on… looking at the fork choice side of things, so basically, that's just it from us.

Justin Traglia: Okay, thank you. And last, but not least, granting.

Subhasish: Anyang, would you like to take it?

hangleang: No, y-you can, you can… We can't speak.

Subhasish: Okay. Yeah, so, mostly, most of the PRs are in place, and we're in the process of, reviewing them. A new PR from the last week was, including the block at stations, and, I am personally answering, reviews on, some of the corrections, pointing at, food choice changes, and, yeah, so it's mostly, correcting and, reviewing the changes.

Justin Traglia: Okay, thank you, everyone. I guess we can get started on some of the other agenda items now. The first one is code for HTTP endpoint. This is something that POTUS wanted to bring up. It's essentially the… the builder API endpoints that would be necessary for a validator to submit bids and stuff. I'm not actually sure if this makes sense anymore, if we plan on Using, like, mountain… If we end up making builders not validators. I'm not the most up-to-date on this one. Maybe, Nico, could you give some more insights on whether or not this is something that Like, what is this, and… Should we be doing this?

Nico Flaig: Yeah, personally, I'm not that convinced it makes sense, to be honest, because usually, like, where you run your validators, so if you assume a solo stake as a beacon node. I don't think you wanna pause that note to submit bits each slot. Because there's, like, if you force the EL to build payloads each slot, it's gonna be a hit on performance. Especially if you think, like, long-term, if blocks are harder to produce, like the payloads, I really don't… Know if that even makes sense.

Justin Traglia: Yeah, I… that makes sense to me. I think it's coming up.

Nico Flaig: Otus was mostly in favor of this, right? And Enrico, I think.

Justin Traglia: Yeah. Francesca?

Francesco D'Amato: Yeah, sorry, could you just restate exactly what is the question?

Justin Traglia: Nico, maybe you'd be able to phrase it better than I could.

Nico Flaig: So basically, the idea is that the beaker node would implement the builder functionality, where you implement the server side of the builder API, like the get header and the submit block API. So that's basically a case if you're a solo staker, or maybe, like, a group like Eve Staker, and you want to act as a builder. That it's more accessible, or they can just run a client and don't need to run any relay or builder software.

Francesco D'Amato: I mean, it seems nice maybe as an opt-in, like, anyway, you would need to be, even without the, fully staked builders, you would anyway would need to opt-in to the whole thing by depositing a builder. So if there was, like, just a flag or something to do this, it seems nice. It definitely seems weird if you were just building blocks for no reason without even having a builder. That you control, but… I don't know.

Justin Traglia: Parents.

Terence Tsao: It's optional. Anyway, and we also have this today already, so I don't think it's, like, each… today we have the flag, right, that's such that you can, like, signal the CL client to basically prepare a payload every slot. And the builder's already using something like this today, and the difference is that we're actually implementing, like, this… we're opening the port, or… having to handle it for the server, that's the only difference. But I think this could be optional. I don't think it's, like, a requirement that client must do this, but, like, if today, say, Nimbus or Lighthouse do it, then Buda can just use the Nimbus and Lighthouse for this functionality.

Justin Traglia: Breath.

Bharath Vedartham: Yeah, I mean, I would assume, like… for clients, if they want to implement, like, I would assume, like, you know, proposers are not gonna whitelist, like, like, ETH Taker, like, solar validators and stuff, right? Because you… you would directly… the builder API would probably, like, whitelist the builders Who, who you're gonna, like… call getHeader and get bid or whatever, right? I would still assume, like, a lot of the… solo builders would… and you kind of need to trust the builder that, okay, like. it's a big enough builder that you know the URLs. Maybe in a future where the URLs are more, like, on-chain, like, I think the builder registry, which people are working on, maybe in that case, like, everyone can publicize the URLs, but today I would assume you would use the builder API for bigger builders?

So, I mean, to me, like, I would… I imagine, like, small solo stakers would probably use the P2P gossip topic. And, yeah, I mean, again, for the… feels kind of weird for clients to implement, the Builder API, like… the server side of the builder API. I think the bigger question for me is, like, whether clients want to implement the… whether the clients want to absorb the entire, like, MavBoost, client-side implementation into The client, or, like, how they would want to do that So, yeah, just… like, the clients can build blocks, but I'm not sure the implementation of the builder API, the server side, to send headers and the beacon block back, makes, like, sense to me, but yeah.

Because I'd assume, like, the smaller validators are not going to be whitelisted by most proposers, so yeah.

Terence Tsao: I think this is just probably optional, like, people can do it if they want to do it, so yeah.

Justin Traglia: So I guess…

Nico Flaig: one consideration. Would be if we separate the builders now, and they are no longer validators, you would not import the keystore and the validator client. So in my mind right now, it's probably a separate process that you can run. like, whatever, Lodestar Builder, and then… that only uses the SSE from the beacon node and, submits bids only via P2P. I'm not really sure about the API part, to be honest.

Justin Traglia: Terrence, you're still unmuted, do you want to say anything?

Terence Tsao: No, I think… yeah, I don't think this is, like, really that big a discussion point. Like, people can do it if they want to do it, but I can support that, so yeah, I mean, this is not, like, this is not meant to be a requirement at all.

Justin Traglia: Okay. Do we still need to standardize this, or specify it?

Terence Tsao: I think it's a very low priority to do that.

Justin Traglia: Okay.

Terence Tsao: It's a very… it's… yeah, it's a nice to-have.

Justin Traglia: Okay, cool. Let's just move on to the next topic, then. Unless anyone has anything else. Okay. The next topic would be, a PR on proposer preferences. I will share the link right now. Sorry, yeah, this is a way for, validators, proposers, to share their fee recipient and gas limit preferences to builders before The proposal slot. I think it's pretty simple. It's via a gossip topic. Fair, The structure is pretty minimal. It includes the proposal slot, the proposer index. Few recipient gas limit, and maybe something else I forget. You would only submit these to the network, The epoch before you're proposing, so it'd be, like, 32 messages per epoch.

Which is fairly minimal. And, I recently changed it from Proposal Epoch to Proposal SWOT, so now if… You're lucky enough to have, multiple, proposals in the same epoch, you would send two messages now, or multiple messages now. It just kind of makes it a bit easier to check and to verify. I know. I guess this is just a request for people to review the PR, and maybe on this call right now we can come to an agreement on whether or not this is something we… Want to merge? Or intend to merge. After it's been properly reviewed. What do people think about this? Nico says, in favor of having this.

Enrico Del Fante: Yeah, I mean, it makes sense to me to complete the whole protocol. Right, this is a… this is a missing piece to be everything without any API. Cool, right.

Justin Traglia: I think so, too.

Enrico Del Fante: Yeah, so, I mean, it makes total sense to me.

Justin Traglia: Breath?

Bharath Vedartham: adding one thing about this is… so we send the… I think it's not an issue, but we send the preferences for epoch E plus 1. If a builder, like, comes, like, if a builder is live, like, becomes active in the previous epoch, like… and hasn't received the preferences, the builder won't be able to build… won't know the preferences for Epoch E Plus One. And I guess that's fine, I mean… Like, unless we want to have a way for that builder to be able to fetch those preferences, but that just seems too complicated to me. Yeah.

Justin Traglia: I agree. I think it'd be better just to, like. Force them to wait another epoch before actually submitting bids. Or they could… yeah, that's… really, that's the easiest solution.

Bharath Vedartham: Yeah, otherwise I'd assume, like, you'd have… clients would have to store the preferences, and you'd have to, like, have a request response or something, which just doesn't make sense. But, yeah, I just wanted to…

Justin Traglia: to put… I suppose you could spin up the, like, builder node before the, builder actually becomes active. So, I mean, maybe it would have this information anyway.

Bharath Vedartham: Yeah, I mean, it's just subscribing to a gossip topic, right?

Justin Traglia: Yeah, there's not too much.

Bharath Vedartham: Yeah. Yeah, I mean, I think.

Justin Traglia: And it…

Bharath Vedartham: that, like… Say?

Justin Traglia: I was… I'm sorry, I was gonna say that, Non-staked builders could also use this gossip topic if they wanted to. But I guess it's not as useful. But yeah.

Bharath Vedartham: Yeah, but… Yeah, I don't think we know if they'll even, like, exist, or we'll even support them. I think that's probably a different problem, but… but yeah, I mean, it's just like listening to a gossip topic, so you have to do that. Just wanted to raise that, like…

Justin Traglia: Okay. It sounds like there's support for this, so please take some time to review it when you can, and I'll try to merge it after I… After it's properly reviewed and approved, and I, making these suggested changes. Thank you. Okay. The next topic is, a bid forwarding threshold. I just shared the link in the chat. This is kind of like a DOS prevention method, or like a… something to help with, like. Preventing DOSes. This PR would change the forwarding threshold, so, like, currently it's, is the bid value greater than the current, or the previous highest bid value? And this could be as small as… as small of a change as, like, one way. This PR would make it to where the new bid would have to be, like, n percent more valuable than the previous highest bid. In the PR, I have 3%, but we could change that to 1, 2, 5, like, whatever makes sense to us.

I think it should be fairly low, though, so… Keep that in mind. I forget what the remarks about it were. I know Quasar Builder had some… What do people think about this? Maybe builders? Lorenzo, do you have any opinions?

Lorenzo: Yeah, I think maybe 3% would be a bit high. I don't have a good feeling, it's just when there is a very, like, high-value blocks, then… You know, bidding in increments of, like. 3% seems very high. I mean, I do see the anti-dose vector, but… Yeah. Not sure if there's, like, a set number that is ideal.

Justin Traglia: Yeah. I'm not sure what the correct number could be, either. Okay. How do other people feel about this? Is this something that we want, or… Aren't we fine without it?

Enrico Del Fante: I think something like that needs to be in. Definitely in favor.

Justin Traglia: Okay, thank you. Please take… or Francesca said, does it matter if the increase is high, the expected usage of this is more just a fallback? I'm not sure. I mean, I think it sort of matters. Lorenzo? Did you answer that?

Lorenzo: No, I think… well, if the goal is just to have an anti-DOS, then… because we bid so frequently anyways, and likely wouldn't use P2P anyways, so yeah, it's just a fallback. But… it's still… I can imagine some cases where we have to use it. In that case, it would matter. It's just… It's something maybe you don't use for, you know, 99% of blocks, and then you use for that single case. So that's why the… Yeah, yeah, it wouldn't happen for high frequency reading, definitely, it's just… you know, the proposal set will be quite varied in general, so I could imagine some blocks will have to use it. Even though that's not ideal.

Justin Traglia: Okay, thank you. Terrence?

Terence Tsao: Yeah, so I think on the implementation side, this is also, like, highly configurable in a way that, like, we can just quick hit once it goes live. I mean, we can start, like, seeing it with a reasonable number, and then once we see DOS, then we just… notify everyone to tweak the number to be higher, and that will likely solve it as well. So that's another way, yeah.

Justin Traglia: Yeah, that might be a good suggestion, too. We could decide to, yeah, keep it in our pocket and only use it. Or only, suggest people use this if necessary.

Terence Tsao: Oh, I mean that we have to use it, but it's just a number, it's like, we can always change it to a higher number later on, yeah.

Justin Traglia: Oh, I see. Okay, sorry. Okay, it sounds like there's general support for this. Maybe we can chat about it some more on the PR. Please take some time to review it. Enter, approve it. Okay, let's move on to the final topic, the non-validator builders. I'll share the link in the channel. We're in the chat. Okay, this is the big change that we've all been sort of working on this week. After speaking with builders, like, for the past couple weeks. We learned that they prefer to avoid the deposit queue and, rather than receive rewards on staked, state to ETH. Like, faster deposits is more important to them. And also, I guess, minimum, or sorry, smaller, staking requirements. So, like, 1 ETH versus 32 ETH is more capital efficient.

Yeah, so we spent a bunch of time working on a PR for this. I think a lot of people have reviewed it. I'm generally in favor of it. What do you all think? Aaron's thumbed up, Nico's thumbed up.

Shane Moore: When I read the non-validator builders, description on the GitHub Ethereum PM, it does say, like, however, we don't want to lose the fallback of P2B biz from actual validators. I'm just curious why we would lose that if we did this design.

Justin Traglia: Yeah, that is the one negative of this, I guess. Yeah, so, like, normal validators wouldn't be able to submit bids like they were… like they could in the current spec. Is your question, like, why is that? Or, like, why.

Shane Moore: Yeah.

Justin Traglia: lighting that.

Shane Moore: Just because.

Justin Traglia: Because, they wouldn't be part of the builder set, like, in this state, so they would have a different set of indices. And, the only thing they could do is self-build.

Shane Moore: Okay. lose the fallback mechanism of, being able to do P2P bids, basically.

Justin Traglia: I know the P…

Shane Moore: Yeah.

Justin Traglia: I mean, the builders would still be able to submit peer-to-peer bids.

Shane Moore: Okay.

Justin Traglia: To be clear. Like, it would just be a… a different staking actor type. Like, it just wouldn't do… it wouldn't have validator duties, pretty much.

Shane Moore: Okay, yeah, I'm following you.

Justin Traglia: Yes, correct. Francesca said anyone could put down 1 ETH and become a builder. And it would be, very quick. Nika?

Nico Flaig: Yeah, just to me, it's not really clear, this argument, that any validator would be a builder. Just from technical perspective, it doesn't make a lot of sense for your validated client node to also produce blocks each slot. Because really, I mean, right now, to me, it makes way more sense to have this separated, and it's also cleaner from a key management perspective. And, run this on a different server, or at least different process. So, I'm really wondering, like, who would be that… those validators that… that we are talking about? Because I don't really even see who would be doing that. And if they want, they, yeah, they can just deposit the one EVE, which should be small enough, for people running early days.

Enrico Del Fante: Yeah, I see the argument that the hardcore… Ethereum guys that really wants to do that anyway won't be. blocked by… The need of a depositing… an if, and essentially spin up the validator, well… new week. Be careful for that. Probably the only downside would be that… Since this use case is very… would be… Less use and require in… Some implementation on client side, probably very few clients will be implementing this. While the other world… Would have been much easier, but… Yeah, aye, aye.

Nico Flaig: But is it really easier? Because for me, like, I don't want the node that is validating to also doing the bidding. I kind of find it nice that it's separate now.

Enrico Del Fante: Yeah, I get this argument, but technical… the technical implementation would be… Different, because then you have to, handle this new special… validator, and you have to have this additional key management on the validator client that is delegated to that only, so it's… I don't know if the detail, but my gut feeling now seems that This is a more special case than before. I might be wrong.

Nico Flaig: Yeah, I mean, I'm also not sure if the code for that should even live on the beacon node side, because then you need to handle different cases. only needs to do the proposal concern, right? Acting as proposer.

Enrico Del Fante: just needs to expose the API for sending stuff over the B2B. Man, only that. it's currently self-bending doesn't require to send anything on the P2P side, so a Bitcoin node won't even… Doesn't even require to have, the… bid gossiping. I mean, descending part. If… Doesn't want to support, builder. flow.

Nico Flaig: Yeah, I guess the idea could be that it's just a sidecar software, the builder, and we could still implement that as a client, and then you just use the Beacon API to submit the bid and listen to SSE events and stuff.

Enrico Del Fante: Yeah, it just… we just probably need to standardize the API on that side. the bid API for the publishing bid API on the Beacon node. And, yeah, maybe events, related events. Once we do that, becomes much easier.

Justin Traglia: Okay. Francesca has asked for me to summarize the open questions left on the PR. The first one that comes to mind is, it's not really open anymore, but we just made a decision. on whether or not builders should use withdrawal requests or voluntary exits, and I think we've come to this decision that we want them to do voluntary exits, because it's a bit simpler and less risky. For them, so that they can continue using their, Execution address, wallet, account, whatever you want to call it. For other stuff, too. The other questions would be… One second… POTUS said something about git index for new builder. He said, flagging this function as a possible problem, don't have it clear yet, but it's something that clients may want to discuss in the breakout. We typically have a global public key to index mapping cache for signature validation, and this type of reusage would make it… make this cache a little more sensitive to be in sync with the head view.

Not against this, just flagging as a possible shot in our foot. Or… I don't entirely understand, I will share a link. In the chat. I'm not sure if there are any other open questions, Nico?

Nico Flaig: Yeah, I was also looking at that, when looking how to implement the builder separation, and In my mind, like, if we have the index reuse, it might be fine to just get the pub key and the index conversion from the state directly. And not use our pub key to index cache. I think it might be fine if the list is not too large. So I guess that's the concern. Because our pub key to index cache is basically append only. While I think that doesn't work if you have index reuse. Or it gets more complicated.

Justin Traglia: Yeah. In the chat, Francesco said, builder exits take 18 days, so not sure that really counts as sensitive to be in sync. Ciao. Yeah. Also, I guess that's a good question, or a good question to bring up, like, is 18 days reasonable? Like, could this be less or more? And it's just, like, a nice round number, 4096 epochs. 4096. Okay. Review that in the PR. I guess the only other…

Francesco D'Amato: Sorry, maybe just one thing to say here is just to say, like, why do we even have this number? Because in principle, like, builders are not actually state, and you could think that they could exit immediately. So just for, you know, other people, they maybe didn't, like, read the whole discussion, the purpose of this exit period. is mostly to… Basically, Put at least some cost to someone just depositing a bunch of stake and then withdrawing it, like, to kind of just blow up the stake, which, I mean, in part, that's mitigated by the… if we have this reusing of the indices, that somewhat mitigates it. But still, like, you could still, I don't know, deposit, like, 100,000 ETH in, like, one ETH increments, and just create, like, 100,000 indices, which may or may not be reused.

And kind of permanently… Potentially pollute the state. And so at least this puts, like, some cost that you can just immediately withdraw it, and just have loaded the state, for, like, you know, one day of depositing and withdrawing. But it's not clear that this is the best way to do this, or, you know, this number is kind of… yeah, just pulled out of a hat, so I don't know. It feels like this is something that maybe we should still… I mean, it's fine for it to be like that, but… Keep it in mind, this purpose, maybe it's still worth discussing, like, is this actually the best way to do this? And, you know, otherwise, what could we do?

Justin Traglia: Yep, and worth mentioning that this is possible with validators today as well. You just send one ETH to the deposit contract, and it would create the validator indexey and keep it in the state. How do people feel about this? Clients, Debs? Okay. There was one other open question, I suppose. A comment from Mikhail. About whether or not we should add, Check prior withdrawals in the builder's… in the builder withdrawals loop. I was arguing that… It's unnecessary, because, like, it's impossible that… Wow. Their balance would be lower than the expected amount.

And, I've read the entire argument, but he's suggesting we add it. If you have an opinion on this, please comment on the PR. Yup. I think that's it. Maybe, Francesco, am I missing anything?

Francesco D'Amato: Not that I can think of right now. About the point from before, I just wanted to add, I think, one difference with the validator loading thing is that I think, if I remember correctly, like, you can't withdraw validators unless it's become active first, so you do need to deposit… like, you can blow the state with one ETH, but if you do want to get it out, you have to first deposit another 31 ETH. So that makes it a bit, like, at least if you want to get the money out, you will need, like, more of a… more of a budget to make this attack. But yeah, it's not like… Fundamentally different, I guess.

Justin Traglia: No, I forgot about that, you are correct.

Francesco D'Amato: But yeah, other than this, I'm not sure, I don't have something else in mind.

Justin Traglia: Okay.

Francesco D'Amato: Ms.

Justin Traglia: Oh, wow.

Francesco D'Amato: Actually, sorry, Lee, I want one more thing. Let me just say… I mentioned this on Discord, but just in case to say it here, so I think… Most of the four-choice pack. is what it is, and it's gonna stay how it is. I mean, of course, you know, people are welcome to review and point out problems, but, like, at least I wouldn't expect it to… to change greatly. It's been like that for a while. There is some sort of, like, things around the edges that I do plan to change, and yeah, someone asked me to link the changes today. I didn't get to that yet, but it's somewhere on Discord, I'll link to it after.

the call. They're kind of old, so it's… yeah, I think they still pretty much… like, the fortress pack hasn't changed, so it's still gonna make sense, but things around it have changed. But yeah, it's more stuff around, let's say, edge cases of the trustless payment stuff. But at least the main, you know, get head and, how the, basically Block 3 works with payloads and all this stuff, like, should stay as is. And most of, also, pretty much all, yeah, most of the stuff around, how do you use the PTC, and, like, all these things are changing… are the same, just what should change is… some things around, like, what exactly do proposers do, and a little bit of, like, how a testers interact with this, but yeah, I would say don't worry about it too much. Just, like, maybe don't…

You know, maybe think too much yet about the defined details of this interaction, because some things will… will… yeah, will change in this, in this PR. And, I mean, yeah, I can also, like, I can link to the discussion that existed about this before, where it's already kind of explained why these changes are, and yeah, what the purpose is.

Justin Traglia: Thank you. There is one more open question, I suppose. It's about whether or not a builder should have a withdrawable epoch field. personally, I don't think this makes sense, but again, please. I'll share link, one second, sorry. Please comment. I think a builder… sorry, I'm quoting Kyle here. I think a builder should also have a withdrawable epoch. Once the exit epoch is reached, the builder becomes inactive, cannot bid, and then until withdrawable epoch, the balance is frozen on the beacon chain. Without that… without that freeze, the DOS protection isn't as strong as it can be. And I stood something like, The builder can't submit a bid if it's initiated an exit, which is sort of a freeze. So, should be the same thing.

Yeah. Yep. For that PR, that's all. Seems like there's support, so if… If you have time, please review the PR, approve it if you agree. If there's a sufficient number of approvals, I'll merge it. I still do need to make the withdrawal request versus voluntary exit change, but I can do that, like, probably in 20 minutes, like, after this breakout call. And then, yeah, after these PRs get merged, I'll make a release. I can do that just whenever… whenever it's ready, pretty much. That's all of the planned agenda items. Is there any other topics? People want to bring up.

Bharath Vedartham: One thing is, we do have, like… like, I've been working on the initial, like, builder API specs, but… But yeah, it's… it's in… I think it's in, like, a decent chip for a review, but I believe, like, people can start reviewing it after the… stake builder's PR gets merged, because there's some dependencies with that, especially the builder index and stuff, so… Yeah, but just, like, want to put that out, like…

Justin Traglia: Yep, thank you. Anything else? Okay, let's end the call, then. Happy holidays, everyone. Enjoy the time off, and see you at ACDT in 2026. Alright, bye, everyone.

Enrico Del Fante: I'll…

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