ePBS: What EthStakers Need to Know

Transcript

Hello hello. Okay. All right, cool. Thanks for having me. I am Terrence. I am from Option Labs. I work on Prism, the consensus layer client. And um yeah, it's funny. I literally had another talk on EPBS in this building 20 minutes ago. But this one is probably going to be slightly more technical than my first one cuz I mean, I'm sure this is a e-staker talk. Most people are here technical and know what EPBS is and know the basic of EIP-7732. So, let's get into it.

So, in terms of agenda, how I'm going to schedule this, I'm going to divide this into four parts and the first part will be like what is the EPBS slot look like comparing to the today slot. In the second part, I thought it may be interesting for you guys to know that EPBS, there's this new committee, it's called payload timeliness committee. Why do we need it? Like what does it do? The third part probably the most relevant to everyone here is the new proposal and builder interaction. How do I buy a block from a builder? How does a builder sell block to me? The fourth part is probably slightly more hand-wavy or high-level. It's like the new gossip subnet you you have to subscribe, the new withdrawal ordering. But client code takes care of that for you already. But

it's good to know that knowledge, right? And um yeah, so this is designed more for like the staker talk. Okay, so this is probably the most important slide of the whole thing. If you just remember this slide, I think that would be awesome. That like what's wrong with the first picture today? The first picture today is what we have today, right? You have 4 seconds to do everything. Download the block, verify the block. This is why gas limit is constrained because you only have 4 seconds. The last 8 seconds is idle in terms of contribution to the gas limit to the blob. EPBS opens everything up.

So, now you have 12 seconds to do everything. You have 12 You have the first 2 seconds for consensus. You have the remaining slot to do execution. And then the blob, you have a 12 seconds to propagate and that is awesome because EPBS improve scalability. So, now you can increase the gas limit by By that picture, you can increase the gas limit by three times, right? If you just look at that picture by itself. And this is literally the core of EPBS. Why we're doing this is to scale. So, as a proposer, as a validator, as as as a e-staker, what do I have to do now?

Well, client software takes care of everything for you, so you don't have to worry about that. But here are the additional things that may change that you should be aware of that as a proposer, if you're proposing, you're selecting a block, you have more resource avenues to select your block. That's the first thing. As a attester, nothing changes. As a builder, if you guys are interested in building, that's awesome. But like you're releasing a block at some certain deadline. So, that's another thing you have to do only if you're a builder. Then the last part is that the 8-second mark or timing is TBD that you may be selected to participate to vote on the payload timeliness. There's no reward, there's no penalty for that. This is

just like a signal for the next slot proposal to use. And um Yeah, so you're So, that's basically the main thing that this new payload attester timeliness duty. And then the next slot proposal also aggregate everything, put the PTC votes in their blog. That's another thing. Then again, client software takes care of everything for you here. So, what are the new validator experience? I don't want to repeat myself so much. But yeah, as a proposer today, you're picking the highest bidder already. Some proposers may be slightly more opinionated in a way. So, therefore, they might not choose the highest bid. They may have their own conflict file to choose the highest bid.

As a attester, that you're also voting on whether the previous payload was revealed correctly or not. So, that's another thing. And then you have this PTC committee. That's a new thing. It's a new committee that votes whether the payloads arrive on time. And the proposer of the next slot are responsible for aggregating the PTC votes in their view. So, why are we doing this? Why do we need PTC committee? This is to ensure safety between the proposer and the builder. Why do we need to ensure safety? Because as a proposer, I sell my block to a builder, I have to get paid, right? But if I'm a builder, I build my block

and then I give it to the proposer. If the proposer failed to meet their end, I shouldn't have to pay, right? But if something goes wrong, who is at fault, right? So, this is basically what the safety property that we're guaranteed with the protocol under EPBS if you use trustless payment. This is why PTC exist. So, what is this PTC committee? It's a small [snorts] committee that is number is 512. So, what does it do? It basically votes whether the builder revealed their block on time.

And then And then And then why is it useful? Because of say that the block was not revealed on time, the next slot proposer, attester can essentially vote to essentially reward the payload. And because of that, you may see like an empty slot. And then what is cool about PTC is that there could be multiple deadlines. For example like you can have a deadline for the payload, then you can also have a deadline for the blob and stuff. So, you have multiple deadline. And that's really cool. PTC can be flexible for that type of use case.

Why does Why do we need PTC? Well, the answer is actually pretty obvious. If you don't have PTC in the middle, then the builder has a lot more power, right? The builder can choose to reveal the payload very, very late at the end of the slot to play timing game. The builder could trick for choice on what is the next head of the chain. And ambiguity is not nice. We don't want ambiguity. So, we need some committee to come together and determine whether the builder do their things correctly. And this is essentially why we need PTC. And then it's worth mentioning PTC, the size chosen is 512. It's quite small comparing to the current attester set because we don't need such large amount

PTC for this, right? In order to corrupt 50% of 512 committee, it takes many, many years to do that. And um last point, yeah. I think Yeah, I think that's basically what I want to cover for PTC. So, I want to now I want to cover more on the auction market. What changes? Today, we have MEV-Boost. We have this relay in the middle. We have this multi-multiplexer. It chooses all the relays for me. And then it's kind of this push and pull market, right? Because the builders submit their block to the relay and then the proposer pulls the bid from the relay, right? So, that you have this relay in the middle, right? And then the visibility-wise, it's like anyone can see

everyone's bid. So, if you see like websites for that, there's websites for that. You can see this like bidding ladder, right? Everyone's trying to bid with each other, which is pretty interesting. But in the EPBS world, everything changes. They are splitting We're splitting MEV-Boost into two different type of market space. There's going to be a P2P market and there will be a RPC market. In the P2P market, it's very easy to join because now you don't have to open your RPC port. You just submit your bid. Assuming you stake some amount, you have some money, you can submit your bid on the P2P market, right? Anyone can listen Anyone can open. The downside is that P2P is slow, right? It takes a while for a bid to propagate. So, you may not be as profitable. You may not win a lot of

times. And this is why we open it up to have another RPC market that's very similar to how MEV-Boost work today. Essentially, as a builder, I pull directly to the Sorry, as a proposer, I pull directly to the builder, right? And then But what's cool about this is that this type of market could be a private market because of like there's no one in the middle, right? So, I can just ask, "Hey builder, can you give me a bid for this slot? Hey builder two, can you give me a bid for this slot?" And then I got a bid back, right? And then because it's private, it's still bid, then there's not so much of latency advantage there as a builder

can do, right? As a builder, if I'm a super fast builder, I'm a super powerful builder, I don't my There's no such a thing as latency advantage here cuz I just request I just respond on what proposer us like send me. So, that's one nice effect there. Um this is just a quick idea um because now we have bid over P2P, as a proposer, how do I choose my preference? For example, right? As a proposer, I want to say, "Here's my fee recipient.

This is the address I want to get paid. Here's my gas limit." And there may be more things, right? How do I communicate that to the builder? So, we have another gossip network for that that the builders can listen to and then the network will help propagating this message among each other. So, this is a way for proposer to express their preferences to the builder. Sorry. And then this is the P2P bid bid gossip I was talking about. So, as a builder, you're registered on chain, you're invited to bid once a slot, right? And then essentially you have to produce a

valid bid. If you're not producing a valid bid, then people may down score you and disconnect with you. But everyone will help propagating your bid, right? The bid may be a little bit bit slower to arrive because of the nature of P2P network, but you are invited to participate. And this is important for the lightness of the network, right? Because if say today all the builders collude on the RPC side, we can still use this P2P bid side to generate competitive bid, for example, right? Such that you don't really have to rely on your local block.

So how does proposal and builder work on P2P? Don't want to go through this too much. I mean a lot of them already said it, right? I think like it's also important to know that like there are some like anti-DoS um mechanism that's built in. So if you are a proposer, you are a node, you cannot get DoS through builders that try to harm the network by sending like 10,000s of bid, right? This is why we only allow builder to send one bid per slot or maybe two bids per slot if the net's paying value is higher.

And yeah. And this is the uh builder RPC. This is basically how like the builder will essentially talk to the proposer through the RPC network. This is like a pool model. So proposer requests bids on demand. And then this is private, like I said. And then yeah, and this is cool because this can be a sealed bid dynamic, which reduces peer latency advantage as well. This the sealed bid the signing may be optional.

We still TBD, but there's a builder API out there that's looking for people's feedback. And some of those can already be tested today. Already on devnet. So highly encourage testing. Um it's worth mentioning that like the bid today there are two values defined. This first value is just called value. So this is the trustless bid. So this are the bid that you are guaranteed to receive as a proposer. They're guaranteed by the protocol.

If if today someone bid 100 there, I'm a proposer, I use that bid, I I do everything correctly, I'm guaranteed to receive 100. But then there's another value is called execution payment, which is only available if you use the RPC network. So this is very similar to today how MEV boost relay builder pays you, right? You you you get this amount, but it's kind of like a EL side transfer. They send it to your fee recipient. But this is execution layer thing. And that this is not guaranteed. This is but there's enough feedback saying that if people want to do things the same way today, they don't want to like we don't want to break everyone's setup. This is

why we have another field that's called execution payment. But this is a trusted field and you are choose to and then you're welcome to use that as well. Client code will definitely consider both and you have configurations such that you can see the both fields, but execution payment is is there such that it is backward compatible with today. So it's worth mentioning layers of trust here just cuz like this is a staker that we want to be honest with like what are the different trust level, right? And then I think the first layer is just like fully trusted, right? Today if you produce a local block, like I trust that local block because of this is my node,

this is my software, I downloaded it, I built it. I will trust whatever block that get, never mind my EL client gives me, right? Even though the local block has very very low value, right? And then so this is ensure lightness. Then the second level of trust is that you will trust something that's guaranteed by the consensus. And those are the block bid from the P2P network. And those are protocol enforced basically, right? And this is what EPBS enable that the protocol enables trustless payment such that you can use that bid over the P2P, right? And [snorts] then the third level of trust is basically what we're having today, right? This with the MEV boost relay. But it is backward compatible.

You can still use that, right? And then so you have this execution payment field. And then this is just like a EL payment like how everything works today, right? So as a proposer, you have options, right? It is getting pretty complicated because I you have to ask yourself how much do I value one, how much do I value two, how much do I value three, or do I just take the highest amount of both, right? So this is can be pretty subjective. This is why client code like Prison, for example, we spend lots of time thinking how to give a nice configuration file such that as a staker, I can express all my preferences.

So this may be how a configuration file look like, right? So you have your main base like today. You want to give your local block a boost. You can give your local block a boost. And for different builders, you can be opinion be opinion be have your own opinion. You can say for this builder, I only want to trust him, but I only want to trust him maximum for one year. That's it. Otherwise, he may like rug pull me or something like that, right? And then you so you can have like different configurations. Trying to be as flexible as possible. This is not set in stone. This is still very open for feedback.

And I'm sure like a staker will be like a very very nice party party to give feedback on this. Uh this is one of the last slides that it's worth talking about how withdrawal work um um with EPBS. Um not much has changed in terms of you won't see so much UX differences. You will still get your withdrawal. Not like nothing really changes there. But knowing that like today the priority is validator partial first, validator sweep second, right? But now we have two more things to add.

So the priority is that the first one is always going to be the builder paying the proposer. But that's just one spot. That's it. That that's it. That that that that that just always going to be one withdrawal. Then validator partial withdrawal second. Then the builder sweep goes third. The builder sweep is when the builder wants to exit from the network. So they can get exit. Again, I don't expect builder taking up much of the space in terms of validator in in terms of the withdrawal ordering queue.

So for partial withdrawal and validator sweep, I think those should basically remain like unchanged. You should still see the same frequency of the withdrawal coming in and out. But it is worth monitoring and it it it is a good questions on just like are the current withdrawal fair? Like does it like hurt the solo staker and stuff? So this is something to maybe think more on. So yeah, so this is one of my last slide. It is my last slide. So thank you for coming to the talk. I just want to shout out like we are currently having devnet right now EPBS on devnet one. So anyone is welcome to participate. This is now a very very

good time to give your feedback as a staker. Something that you don't like, something that you like. I mean there's some API stuff, config file are can still be changed today, right? And then yeah, and then yeah, and it's worth mentioning that you guys are very very important in this ecosystem. So we will definitely like feedback from you. And then in terms of timeline, I think like it's very possible to do this like in Q3 and stuff. So I think we're getting there. We're making good progress. So yeah, thank you guys. >> [applause] >> Do you have anything that you anticipate

people might want to have changed about the config file? Like what where would you say we should start Yeah, I Yeah, so I think proposer it's a very like they I think they they they rightfully should be pretty opinionated because of like regulatory like like because of regulatory restriction. And as we learned today, it turns out I I learned that a couple months ago that like a lot of proposers, they can only work with OFAC compliance relay, for example, and builder, for example, right? And then the question is just like how can we And today relay does a lot of work to to basically help with that thing, right? Then say the relay goes away. Now you just have a proposer and a builder and no one in the

middle to help. Like how can a proposer help with that? And I think this is where the config file comes into the picture that how can we define those type of preferences for a proposer? Say proposer, I say this proposer, I cannot work with a builder in like North Korea. And what do we do there, right? And this is something that we probably want to think more on how how to define that in the in in the file. Thank you.