Justin Traglia:Hello, everyone. Welcome to EPBS Breakout Call 29. This is the final breakout call for ePBS.
Transcript
Justin Traglia:After which, starting in 2026, EPBS discussions will take place at ACDT.
Justin Traglia: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: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.
terence:And, the… and the SSD status structure.
terence: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: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.
Justin Traglia: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:Sounds fair.
Justin Traglia:Okay, thanks. Is there anyone here from Lighthouse that can give us an update? If any update?
Justin Traglia: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.
Shane Moore: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 (tbenr):Yeah, not that much. Updates. This week has been…
Enrico Del Fante (tbenr):Along with Raz, Stephanie is off, and yeah, the only… the last thing we were working on… actually, Mehdi was working on it.
Enrico Del Fante (tbenr):Still related to, gossip validation rules that needs to be…
Enrico Del Fante (tbenr):Redesigned a little bit to make it a better cross-fork.
Enrico Del Fante (tbenr):Aware…
Enrico Del Fante (tbenr):And, yeah, not that much progress still on that, so I don't know if Meli wants to add anything.
Enrico Del Fante (tbenr):Probably.
Mehdi Aouadi:No, that's basically it, yeah, I've been working on the Gossip player, so, yeah.
Enrico Del Fante (tbenr):So, yeah, that's it.
Justin Traglia:Okay, and Stefan's been on vacation, right?
Enrico Del Fante (tbenr):Yeah, it is, yeah, I think Lee will be back next year.
Enrico Del Fante (tbenr):And most of us will be starting…
Enrico Del Fante (tbenr):Going off from… from today, so… Yep.
Justin Traglia:Expected. Same for me.
Justin Traglia:Okay, thank you for the update. Is there anyone here from Nembos that can give us an update?
Justin Traglia:I don't think anyone from members sits here. Okay.
Justin Traglia:Lodestar?
NC:From Lostar's side, we got, concept topic, concert validation.
NC:We got the opt for… Seen cash, done.
NC: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?
Justin Traglia:What is that?
NC:Yes.
NC:So, basically,
NC:Yeah, just basically, instead of just importing, like, a single block, you import the consensus block.
NC:And then you have, like, this intermediate beacon state that we need to store somewhere.
NC: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.
Justin Traglia:Okay, thanks.
Justin Traglia: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.
Caleb: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.
Justin Traglia: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
Subhasish: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.
Justin Traglia:I guess we can get started on some of the other agenda items now. The first one is code for HTTP endpoint.
Justin Traglia:This is something that POTUS wanted to bring up. It's essentially the…
Justin Traglia: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
Justin Traglia:Using, like, mountain…
Justin Traglia: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
Justin Traglia:Like, what is this, and… Should we be doing this?
nflaig: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.
nflaig:I don't think you wanna pause that note to submit bits each slot.
nflaig:Because there's, like, if you force the EL to build payloads each slot, it's gonna be a hit on performance.
nflaig:Especially if you think, like, long-term, if blocks are harder to produce, like the payloads, I really don't…
nflaig:Know if that even makes sense.
Justin Traglia:Yeah, I… that makes sense to me.
Justin Traglia:I think it's coming up.
nflaig:Otus was mostly in favor of this, right? And Enrico, I think.
Justin Traglia:Yeah. Francesca?
Francesco: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.
nflaig: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.
nflaig: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.
nflaig:That it's more accessible, or they can just run a client and don't need to run any relay or builder software.
Francesco: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.
Francesco: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.
Francesco:That you control, but… I don't know.
Justin Traglia:Parents.
terence:It's optional.
terence: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.
terence: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…
terence: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
terence:for this functionality.
Justin Traglia:Breath.
Bharath:Yeah, I mean, I would assume, like…
Bharath: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
Bharath:Who, who you're gonna, like…
Bharath:call getHeader and get bid or whatever, right? I would still assume, like, a lot of the…
Bharath:solo builders would… and you kind of need to trust the builder that, okay, like.
Bharath: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?
Bharath:So, I mean, to me, like, I would… I imagine, like, small solo stakers would probably use the P2P gossip topic.
Bharath:And, yeah, I mean, again, for the…
Bharath:feels kind of weird for clients to implement, the Builder API, like…
Bharath:the server side of the builder API.
Bharath: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
Bharath:The client, or, like, how they would want to do that So, yeah, just…
Bharath: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.
Bharath:Because I'd assume, like, the smaller validators are not going to be whitelisted by most proposers, so yeah.
terence: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…
nflaig:one consideration.
nflaig:Would be if we separate the builders now, and they are no longer validators, you would not import the keystore and the validator client.
nflaig:So in my mind right now, it's probably a separate process that you can run.
nflaig:like, whatever, Lodestar Builder, and then…
nflaig: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: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:I think it's a very low priority to do that.
Justin Traglia:Okay.
terence: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.
Justin Traglia:Unless anyone has anything else.
Justin Traglia:Okay. The next topic would be, a PR on proposer preferences. I will share the link right now.
Justin Traglia:Sorry, yeah, this is a way for, validators, proposers, to share their fee recipient and gas limit preferences to builders before
Justin Traglia:The proposal slot.
Justin Traglia:I think it's pretty simple. It's via a gossip topic.
Justin Traglia:Fair, The structure is pretty minimal. It includes the proposal slot, the proposer index.
Justin Traglia:Few recipient gas limit, and maybe something else I forget.
Justin Traglia:You would only submit these to the network,
Justin Traglia:The epoch before you're proposing, so it'd be, like, 32 messages per epoch.
Justin Traglia:Which is fairly minimal.
Justin Traglia:And, I recently changed it from Proposal Epoch to Proposal SWOT, so now if…
Justin Traglia:You're lucky enough to have,
Justin Traglia:multiple, proposals in the same epoch, you would send two messages now, or multiple messages now.
Justin Traglia:It just kind of makes it a bit easier to check and to verify.
Justin Traglia:I know.
Justin Traglia: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…
Justin Traglia:Want to merge?
Justin Traglia:Or intend to merge.
Justin Traglia:After it's been properly reviewed.
Justin Traglia:What do people think about this?
Justin Traglia:Nico says, in favor of having this.
Enrico Del Fante (tbenr):Yeah, I mean, it makes sense to me to complete the whole protocol.
Enrico Del Fante (tbenr):Right, this is a… this is a missing piece to be everything without any API.
Enrico Del Fante (tbenr):Cool, right.
Justin Traglia:I think so, too.
Enrico Del Fante (tbenr):Yeah, so, I mean, it makes total sense to me.
Justin Traglia:Breath?
Bharath: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…
Bharath: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…
Bharath: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.
Bharath:Yeah.
Justin Traglia:I agree. I think it'd be better just to, like.
Justin Traglia:Force them to wait another epoch before actually submitting bids.
Justin Traglia:Or they could… yeah, that's… really, that's the easiest solution.
Bharath: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.
Bharath: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.
Justin Traglia:So, I mean, maybe it would have this information anyway.
Bharath:Yeah, I mean, it's just subscribing to a gossip topic, right?
Justin Traglia:Yeah, there's not too much.
Bharath:Yeah.
Bharath:Yeah, I mean, I think.
Justin Traglia:And it…
Bharath:that, like… Say?
Justin Traglia:I was… I'm sorry, I was gonna say that,
Justin Traglia:Non-staked builders could also use this gossip topic if they wanted to.
Justin Traglia:But I guess it's not as useful.
Justin Traglia:But yeah.
Bharath:Yeah, but… Yeah, I don't think we know if they'll even, like, exist, or we'll even support them.
Bharath: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.
Bharath:Just wanted to raise that, like…
Justin Traglia:Okay.
Justin Traglia: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…
Justin Traglia:After it's properly reviewed and approved, and I, making these suggested changes.
Justin Traglia:Thank you.
Justin Traglia:Okay. The next topic is, a bid forwarding threshold. I just shared the link in the chat.
Justin Traglia:This is kind of like a DOS prevention method, or like a… something to help with, like.
Justin Traglia:Preventing DOSes.
Justin Traglia: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.
Justin Traglia: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.
Justin Traglia:I think it should be fairly low, though, so… Keep that in mind.
Justin Traglia:I forget what the remarks about it were.
Justin Traglia:I know Quasar Builder had some…
Justin Traglia: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.
Lorenzo:I don't have a good feeling, it's just when there is a very, like, high-value blocks, then…
Lorenzo:You know, bidding in increments of, like.
Lorenzo:3% seems very high. I mean, I do see the anti-dose vector, but… Yeah.
Lorenzo:Not sure if there's, like, a set number that is ideal.
Justin Traglia:Yeah.
Justin Traglia:I'm not sure what the correct number could be, either.
Justin Traglia:Okay. How do other people feel about this? Is this something that we want, or…
Justin Traglia:Aren't we fine without it?
Enrico Del Fante (tbenr):I think something like that needs to be in.
Enrico Del Fante (tbenr):Definitely in favor.
Justin Traglia:Okay, thank you.
Justin Traglia:Please take… or Francesca said, does it matter if the increase is high, the expected usage of this is more just a fallback?
Justin Traglia:I'm not sure. I mean, I think it sort of matters.
Justin Traglia:Lorenzo?
Justin Traglia: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.
Lorenzo:But…
Lorenzo:it's still… I can imagine some cases where we have to use it. In that case, it would matter. It's just…
Lorenzo:It's something maybe you don't use for, you know, 99% of blocks, and then you use for that single case.
Lorenzo:So that's why the… Yeah, yeah, it wouldn't happen for high frequency reading, definitely, it's just…
Lorenzo:you know, the proposal set will be quite varied in general, so I could imagine some blocks will have to use it.
Lorenzo:Even though that's not ideal.
Justin Traglia:Okay, thank you. Terrence?
terence: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…
terence: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.
Justin Traglia:Or only, suggest people use this if necessary.
terence: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.
Justin Traglia: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.
Justin Traglia:Enter, approve it.
Justin Traglia:Okay, let's move on to the final topic, the non-validator builders.
Justin Traglia:I'll share the link in the channel.
Justin Traglia:We're in the chat.
Justin Traglia:Okay, this is the big change that we've all been sort of working on this week.
Justin Traglia:After speaking with builders, like, for the past couple weeks.
Justin Traglia:We learned that they prefer to avoid the deposit queue and, rather than receive rewards on staked,
Justin Traglia:state to ETH. Like, faster deposits is more important to them.
Justin Traglia:And also, I guess, minimum, or sorry, smaller, staking requirements. So, like, 1 ETH versus 32 ETH is more capital efficient.
Justin Traglia:Yeah, so we spent a bunch of time working on a PR for this.
Justin Traglia:I think a lot of people have reviewed it. I'm generally in favor of it.
Justin Traglia:What do you all think?
Justin Traglia: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.
Justin Traglia:Yeah, so, like, normal validators wouldn't be able to submit bids like they were… like they could in the current spec.
Justin Traglia: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.
Justin Traglia:And, the only thing they could do is self-build.
Shane Moore:Okay.
Shane Moore: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.
Justin Traglia: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.
Justin Traglia:And it would be, very quick. Nika?
nflaig: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.
nflaig: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.
nflaig:And, run this on a different server, or at least different process.
nflaig: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.
nflaig: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 (tbenr):Yeah, I see the argument that the hardcore…
Enrico Del Fante (tbenr):Ethereum guys that really wants to do that anyway won't be.
Enrico Del Fante (tbenr):blocked by… The need of a depositing…
Enrico Del Fante (tbenr):an if, and essentially spin up the validator, well…
Enrico Del Fante (tbenr):new week. Be careful for that.
Enrico Del Fante (tbenr):Probably the only downside would be that…
Enrico Del Fante (tbenr):Since this use case is very… would be…
Enrico Del Fante (tbenr):Less use and require in…
Enrico Del Fante (tbenr):Some implementation on client side, probably very few clients will be implementing this.
Enrico Del Fante (tbenr):While the other world… Would have been much easier, but… Yeah, aye, aye.
nflaig:But is it really easier? Because for me, like, I don't want the node that is validating to also doing the bidding.
nflaig:I kind of find it nice that it's separate now.
Enrico Del Fante (tbenr):Yeah, I get this argument, but technical… the technical implementation would be…
Enrico Del Fante (tbenr):Different, because then you have to, handle this new special…
Enrico Del Fante (tbenr):validator, and you have to have this additional key management on the validator client that is delegated to that only, so it's…
Enrico Del Fante (tbenr):I don't know if the detail, but my gut feeling now seems that
Enrico Del Fante (tbenr):This is a more special case than before.
Enrico Del Fante (tbenr):I might be wrong.
nflaig: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.
nflaig:only needs to do the proposal concern, right? Acting as proposer.
Enrico Del Fante (tbenr):just needs to expose the API for sending stuff over the B2B.
Enrico Del Fante (tbenr):Man, only that.
Enrico Del Fante (tbenr):it's currently self-bending doesn't require to send anything on the P2P side, so a Bitcoin node won't even…
Enrico Del Fante (tbenr):Doesn't even require to have, the… bid gossiping.
Enrico Del Fante (tbenr):I mean, descending part.
Enrico Del Fante (tbenr):If… Doesn't want to support, builder.
Enrico Del Fante (tbenr):flow.
nflaig: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 (tbenr):Yeah, it just… we just probably need to standardize the API on that side.
Enrico Del Fante (tbenr):the bid API for the publishing bid API on the Beacon node.
Enrico Del Fante (tbenr):And, yeah, maybe events, related events.
Enrico Del Fante (tbenr):Once we do that, becomes much easier.
Justin Traglia:Okay.
Justin Traglia: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.
Justin Traglia: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.
Justin Traglia:For them, so that they can continue using their,
Justin Traglia:Execution address, wallet, account, whatever you want to call it.
Justin Traglia:For other stuff, too.
Justin Traglia:The other questions would be…
Justin Traglia:One second… POTUS said something about git index for new builder.
Justin Traglia: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.
Justin Traglia:Not against this, just flagging as a possible shot in our foot.
Justin Traglia:Or… I don't entirely understand, I will share a link.
Justin Traglia:In the chat.
Justin Traglia:I'm not sure if there are any other open questions, Nico?
nflaig:Yeah, I was also looking at that, when looking how to implement the builder separation, and
nflaig: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.
nflaig:And not use our pub key to index cache.
nflaig:I think it might be fine if the list is not too large.
nflaig:So I guess that's the concern.
nflaig:Because our pub key to index cache is basically append only.
nflaig:While I think that doesn't work if you have index reuse.
nflaig:Or it gets more complicated.
Justin Traglia:Yeah.
Justin Traglia:In the chat, Francesco said, builder exits take 18 days, so not sure that really counts as sensitive to be in sync.
Justin Traglia:Ciao.
Justin Traglia:Yeah. Also, I guess that's a good question, or a good question to bring up, like, is 18 days reasonable?
Justin Traglia:Like, could this be less or more?
Justin Traglia:And it's just, like, a nice round number, 4096 epochs.
Justin Traglia:4096.
Justin Traglia:Okay.
Justin Traglia:Review that in the PR.
Justin Traglia:I guess the only other…
Francesco: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.
Francesco:is mostly to… Basically, Put at least some cost to someone just depositing a bunch of
Francesco: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.
Francesco: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.
Francesco:And kind of permanently… Potentially pollute the state.
Francesco: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…
Francesco: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…
Francesco: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.
Justin Traglia:You just send one ETH to the deposit contract, and it would create the validator indexey and keep it in the state.
Justin Traglia:How do people feel about this? Clients, Debs?
Justin Traglia:Okay.
Justin Traglia:There was one other open question, I suppose. A comment from Mikhail.
Justin Traglia:About whether or not we should add,
Justin Traglia:Check prior withdrawals in the builder's… in the builder withdrawals loop.
Justin Traglia:I was arguing that… It's unnecessary, because, like, it's impossible that… Wow.
Justin Traglia:Their balance would be lower than the expected amount.
Justin Traglia: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.
Justin Traglia:Yup.
Justin Traglia:I think that's it. Maybe, Francesco, am I missing anything?
Francesco: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
Francesco: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.
Francesco: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…
Francesco:Fundamentally different, I guess.
Justin Traglia:No, I forgot about that, you are correct.
Francesco:But yeah, other than this, I'm not sure, I don't have something else in mind.
Justin Traglia:Okay.
Francesco:Ms.
Justin Traglia:Oh, wow.
Francesco: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…
Francesco:Most of the four-choice pack.
Francesco: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…
Francesco: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.
Francesco:the call. They're kind of old, so it's… yeah, I think they still pretty much…
Francesco: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.
Francesco: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,
Francesco:how do you use the PTC, and, like, all these things are changing… are the same, just what should change is…
Francesco: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…
Francesco:You know, maybe think too much yet about the defined details of this interaction, because some things will… will…
Francesco: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.
Justin Traglia:There is one more open question, I suppose. It's about whether or not a builder should have a withdrawable epoch field.
Justin Traglia:personally, I don't think this makes sense, but again, please.
Justin Traglia:I'll share link, one second, sorry.
Justin Traglia:Please comment.
Justin Traglia: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.
Justin Traglia:Without that… without that freeze, the DOS protection isn't as strong as it can be.
Justin Traglia:And I stood something like,
Justin Traglia: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.
Justin Traglia:Yeah.
Justin Traglia:Yep.
Justin Traglia:For that PR, that's all. Seems like there's support, so if…
Justin Traglia: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.
Justin Traglia: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.
Justin Traglia:And then, yeah, after these PRs get merged, I'll make a release.
Justin Traglia:I can do that just whenever… whenever it's ready, pretty much.
Justin Traglia:That's all of the planned agenda items. Is there any other topics?
Justin Traglia:People want to bring up.
Bharath:One thing is,
Bharath:we do have, like… like, I've been working on the initial, like, builder API specs, but…
Bharath: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…
Bharath:stake builder's PR gets merged, because there's some dependencies with that, especially the builder index and stuff, so…
Bharath:Yeah, but just, like, want to put that out, like…
Justin Traglia:Yep, thank you.
Justin Traglia:Anything else?
Justin Traglia:Okay, let's end the call, then. Happy holidays, everyone. Enjoy the time off, and see you at ACDT in 2026.
Justin Traglia:Alright, bye, everyone.
Enrico Del Fante (tbenr):I'll…
Chat Logs
00:04:23
Stefan Starflinger:gm
00:11:42
Justin Traglia:Also sorry, forgot to share the agenda: https://github.com/ethereum/pm/issues/1835
00:12:22
terence:+1 im confused what the request is
00:14:31
Justin Traglia:Is this something we need to standardize/specify?
00:17:42
Justin Traglia:https://github.com/ethereum/consensus-specs/pull/4777
00:19:21
nflaig:in favor of having this
00:22:08
Justin Traglia:https://github.com/ethereum/consensus-specs/pull/4792
00:24:08
Yassine Ferhane:In favor
00:24:15
Francesco:Does it matter if the increase is high? The expected usage of this is more just a fallback
00:25:00
Francesco:Yeah that’s what I mean, I wouldn’t expect high-frequency bidding to happen there
00:25:12
Francesco:Replying to "Yeah that’s what I m..."
And if there’s a case when bidding must happen through p2p, I guess we take the hit
00:26:31
Justin Traglia:https://github.com/ethereum/consensus-specs/pull/4788
00:27:37
Lorenzo:strongly in favour from the builder side
00:28:26
nflaig:just deposit 1 ETH if you want that
00:28:52
Francesco:And anyone could now put down 1 ETH and become a builder
00:30:16
Francesco:Hopefully client teams can run 1 ETH builders 👀
00:30:28
Francesco:Replying to "Hopefully client tea..."
At least Potuz lol
00:30:39
Colin Kelly:For the X% greater than the previous bid, are block builders fine with having to potentially "cancel" prior blocks by submitting a higher bid?
00:31:12
Lorenzo:Replying to "For the X% greater..."
Yes that's expected
00:31:53
Colin Kelly:Replying to "For the X% greater..."
oh I'm surprised they're fine with it. But thats great then.
00:32:27
Lorenzo:Replying to "For the X% greater..."
Unless I'm misunderstanding your question, this is exactly what happens every time you bid higher no?
00:32:37
Francesco:@Justin Traglia could you summarize open questions on the PR, if any?
00:32:45
Justin Traglia:Replying to "@Justin Traglia coul..."
Yes
00:34:38
Justin Traglia:https://github.com/ethereum/consensus-specs/pull/4788#discussion_r2629133388
00:35:07
Francesco:Builder exits take 18 days, so not sure if that really counts as “sensitive to be in sync"
00:36:10
NC:It really depends how much this p2p bids mechanism is used if we need to have pubkey/index cache for builder
00:37:24
Colin Kelly:Replying to "For the X% greater..."
Oh some builders exposed to CEX txs might need to quickly remove the CEX txs from their blocks if the tx is no longer wanted by the CEXs. And since the block no longer contains the CEXs its at a much lower value.
00:38:01
Justin Traglia:https://github.com/ethereum/consensus-specs/pull/4788#discussion_r2634599814
00:39:21
Lorenzo:Replying to "For the X% greater..."
I see, but the issue is that actual cancels would not be enforceable anyways in p2p. Since there's no way to invalidate your prior bid
00:41:55
Francesco:What’s the purpose?
00:41:56
Justin Traglia:https://github.com/ethereum/consensus-specs/pull/4788#discussion_r2622901736
00:43:29
Bharath:https://github.com/ethereum/builder-specs/pull/138
Summary
8 highlights
· 4 action itemsExperimental
Summary
8 highlights · 4 action itemsExperimentalorganizational
- Final EPBS breakout call; discussions move to ACDT in 202600:04:06
client updates
protocol changes
- Proposer preferences gossip topic PR ready for review and merge00:17:42
- Bid forwarding threshold (3% minimum increase) proposed for DOS prevention00:22:08
- Non-validator builders: 1 ETH deposit, no validator duties, separate indices00:26:31
- Builder index reuse may complicate pubkey-to-index caching across clients00:34:38
- 18-day builder exit period prevents state bloat from rapid deposit/withdraw cycles00:39:04
Decisions
Action Items
- All client teams: Review proposer preferences PR (4777) for gossip-based fee recipient/gas limit sharing00:18:11
- All client teams and builders: Review bid forwarding threshold PR (4792) and comment on appropriate percentage00:26:11
- All client teams: Review non-validator builders PR (4788); comment on open questions00:32:45
- All teams: Review builder API specs PR after staked builders PR merges00:43:29
Targets
- Next week - New consensus-specs release after current PRs merge00:04:22