From MEV-Boost to ePBS: The Protocolization of Proposer-Builder Separation

Transcript

All right, test test. All right. Hey guys, I am Terence. I'm from Optional Labs. I work on Prism. I'm an Ethereum core developer. And today I want to talk to you about the next hard fork, which is Glamours and then and what we're doing with it. And the headliner for it is EPBS EIP 7732. And I want to talk to you about why EIP 7732 is so cool. So, I will split this talk into multiple sections. And the first section will be like why why are we doing EPBS at all? Then the second section will be like what is EPBS?

Then obviously the benefit of EPBS is scaling. So, how does it scale? Finally, there are additional benefits of EPBS such as you get more trust, you get better market structures, and you get more for example like privacy and stuff. So, yeah, let's get to it. So, scaling has been the main priority of Ethereum for the last 2 years as you know, right? EF put a blog post on we need to scale. That's the number one priority. And last year we delivered that with Peer Dust, right? Peer Dust scales data through something, right? So, now you can have more data. And that is cool.

But this year we're going to take it another step further. We're going to scale both execution and data. But this time it wouldn't be some fancy cryptography. You don't need to know about KZG. You don't need to know about erasure coding. This is just do something that's very simple. We call this pipelining, okay? And it's important to mention that in any of those two cases we're scaling without sacrificing decentralization, right? We're not asking nodes to have more powerful hardware. We're not asking you to upgrade your internet. And those are the things that we're doing today that to ensure that scaling is happening, but the network remains decentralized.

So, what is the bottleneck today, right? As today maybe many of you guys run a node, you run a validator. Like there are two things, maybe three things, but two main things are essentially download. You need to download the block in order to know if the block is valid. Then you need to verify the block to know the block is valid, right? Downloading takes time. Just like downloading anything on the internet takes time. And this is not something that I can easily upgrade, right? I can go buy a new computer, I can go upgrade. I I can buy a new CPU, new more memory. But it's very very hard to move my house because of my internet is slow, right? So, this is something that's always on top of our mind. Like how do we uh

essentially reduce bandwidth, right? And then the another thing is just to verify a block each time to verify a block, to verify a payload. And this is something that has to do with gas limit, right? The higher the block size, then maybe there's more room for attackers to attack, then it takes longer to verify the block. And and it's important to mention both of them must be complete within 4 seconds. This is the slot anatomy today. Bef- If the block doesn't get downloaded or verified within 4 seconds, there's a chance the block will not land on chain.

So, this is the Ethereum slot today, right? Today as you many know, the max gas limit is 60 million gas, and then we can have 21 blobs. Those are the max throughput of the chain, right? But you can see what's wrong with this picture as many of you guys can tell, right? You have the first you have the first 4 seconds that's just doing tons of things. We're downloading, we're verifying. Then the last 8 seconds there are something that's happening in the background. We're we're like do some aggregation votes. But nothing in the last 8 seconds has any contribution to to to basically the throughput of the chain, right? As you can see, right? So, the idea is that okay, what if we can use the last 8 seconds to increase

the chain throughput. What if we allow a bigger block, a bigger payload, but using the last 8 seconds to do it? That's the core of the idea. So, what is EPBS? EPBS basically does three things, right? The first is that it decoupled the consensus block with the execution payload. Today they are transmitted as one object, but they don't have to be transmitted as one object. Second, because we decouple the block and the payload, therefore we need a new committee, a new set of new validators to vote that the payload is revealed correctly. This is for the safety of the chain.

The third thing is that because of we have this separation between the builder and the validator, the builder is now staked on chain. Their identity is not on chain. They have to they they they're not staking to do validating duty, but they're staking in order to pay the proposer. This is optional uh through trustless payment. And it's nice because this payment is enforced by political rules. Okay, so decoupling consensus from execution. So, this is a very quick slide. I don't have to go through too much. Just a mental picture is that before MBV boost, everything is is together. The block and the payload are transmitted as one object. That's why

they're slow. They must arrive together, right? But after EPBS, you can see they're split into different objects. So, it's like the analogy is that like you have these big cars in the highway and then this big truck and then they're moving very slowly on one lane. What if we split the truck into multiple smaller cars and put them in different lanes such that that such that they should arrive faster. Okay, so this is what now a new EPBS slot look like. You can see it's so much better than before, right? Now you have the whole slot that's doing things. You have the first 2 seconds that's downloading and verifying the consensus block, and then you have the remaining time to download and validate the consensus payload, and then you have the

whole slot to download the block, right? You can see this is much much much improvement than before. Okay, I do want to mention there are like things that's slightly different than how we do things today. The first is the auction market. Today if you are a proposer, if you want to propose a block, you have the option to use MBV boost, right? And then the MBV boost is essentially a multiplexer.

It allows you to multiplex through different relayers, and then you get the best bid, right? So, this is kind of like a push and pull type of market because the relayer is the trusted party in the middle, and then the proposer asks the relayer for giving the best bid. And then the builders are submitting their bid to the relayer, and then the relayer is kind of this referee in the middle to ensure uh to basically ensure the correct party is getting paid, right? And then let's go through the MBV boost more. And then in terms of visibility, currently how this works today is that everyone like all the builders, they can see each other's bid because this is kind of like

an open market, right? So, then if I see you bid like 0.01 ETH, if I have something better, I will bid 0.0111 ETH, right? So, I will try to beat you until my threshold, right? And then today the bids are cancelable. So, we can send the relayer relayer I actually don't like the last amount I bid. I'm going to cancel it. And then today there's this notion of like timing game because of as you know, the more times you have, the more MBV you have, the more profitable the block is, right? So, when you request something from the block, assuming you're not the one that's playing the timing game, the relayer may delay the return for a few seconds just because now you get a more profitable block, right? And the relayer might also get

the cut, right? So, because of the structure change in EPBS, we're going to split that into two different markets. There's going to be a P2P market that's fully trustless, and then we're going to have an RPC market that's same as today like MBV boost, right? So, let's talk about the P2P market. So, the P2P market is kind of like trustless in a way that anyone can be a builder. Today you can be a builder. You don't have to open your RPC endpoint if you don't want to because of that's that's safe because that's too much work, right? You can go on the chain to register to be a builder. You stake some amount, and then you can broadcast your bid onto P2P. And then

the and then the proposal will pick it up and and consider it, right? The downside of that is slow. So, I can imagine like if you like those P2P bids are probably not going to win most of the time, but it's important for fallback for like liveness of the chain, right? If today all the centralized builder RPC disappear, then we have to rely on P2P bid. And that's okay, right? And then and then now we go to the RPC side of thing. The RPC side of thing is exactly the same as today. You have the proposers, you request bid through high fast RPC endpoint. But this time you don't have to go through the relayer. I

mean, you can go through the relayer if if you want, but they may be slower and the relayer has to be staked the relayer has to be staked, right? So, you go through the RPC provider, and then you essentially get all the bids from the builders through the RPC provider. And then the interesting aspect of that is that because of now you don't go through the relayer, the bid amount only in the proposal can see the builder's bid. And they may have like nice secondary benefits such as now because of that um you don't have this latency advantage.

So, today like the builders and relays they're competing on late on basically who's the fastest. Because of this like nature of the sealed bid auction that like only proposals can see your bid that you kind of even the competition law. Um worth mentioning timing game may still exist because of this because of like the builders can still delay your return. Also, the validator can still play timing game as well. So, there are essentially like three bid sources, right? Because now as a proposer I can consider like which one has the highest value and I

choose it, right? But some proposers may be slightly more opinionated because of like regulation because of like so preferences. Right? Today you look at how things work today. Today about 98% of the validators uses MEV-Boost, but only 90% of them like actually the bid length on chain, right? Because proposers has certain things like MEV-Boost. They will only use MEV-Boost if it's above X amount and something like that. So, you since you have three bid sources to like consider and things gets a lot more interesting, right? So, let's go through them one by one. So, the builder API. So, this is the RPC side. This is the This is the fast one.

This is sealed bid. This is chaining pool. And then the proposer requests bids from the white listed builder and only the proposer can see the builder's bid. So, this is one source you can use. Another source you can use is like I said it's the P2P side, right? You can listen to builder's bid through P2P. And then I hope to see lots of builders bidding through P2P it since it's more permissionless. And then it also act as a competition floor such that if the builder API side everyone collude that if the P2P gossip side like can basically remain trustless, right? It's also a nice like liveness and safety backup.

Then you also have the local block which as you know if you're a solo staker or if you even just staking general, you always have this local block as a background, right? If today number one number two failed or number one and number two's values are lower than local block, you would just use local block and that's okay. But unfortunately, local block value is fairly low these days just because of like private order flow. So, most of the transactions most of the valuable transactions are not going to be on the main pool, right? And therefore, local block typically don't win. But it's nice to have a backup for that.

So, what are the trust and market improvements, right? Like I said before, I think there are three things that's worth calling out. The first thing is that today as a builder when I submit something, I have to go through the relay. I cannot access proposer directly, right? So, that means the relay can see my block, right? And so you're in a way maybe not so bad, but you're leaking information to the relay, right? And then I don't know how that relationship is like, but then as a as a builder, perhaps I have some like information that I don't want to reveal to anyone except for myself, right? But I don't want to go through the relay.

So, this kind of EPBS enables this type of use case that I can access the proposer directly without the relay. That's one thing. The second thing is that you get trustless payment, right? So, today the payment is trusted in a way you have this relay that's escrowing the payment because of this principal agent problem, right? The builder paying proposer so their block can be on chain. The proposer wants to get paid such that you you basically such such that to use the builder block, but if either one of them fail like who's fault it is, right? Does the proposer get paid or does the proposer not get paid? So, we solve the

trustless problem through protocol right now through four choice. And then yeah, so this is different than having relay escrow this and then becoming like the referee and deciding. The third thing is on-chain accountability. So, because of the builders their identity are registered on chain, you know who is at fault very very fast. If today you see a block that's proposed incorrectly or invalid, if you today you see a block even like there's something wrong with it if you see censorship, you don't have to accept from that builder again. And that's very very fast. That can be coded in client software if if if if you want to.

Because of the builder's identity is on chain. And today this is impossible because there's multiple layers of abstraction, right? If something goes wrong, then who is at fault? You don't know if it's the relay is at fault. You don't know if it's MEV-Boost is at fault. You don't know if if the builder is at fault. But the improvement here is just such that like you can like blacklist people faster and hopefully you should see less missing block. Okay. So, this is probably like the last few slides I have and then like I'm just like going to go through like what we talk about. Just basically repeat myself again. Why why are we doing EPBS, right?

The first reason we're doing EPBS is because of the scaling benefit. I mean that's the most obvious reason. Instead of utilizing the slot 12 second about like uh 33% of the time, now we can use the slot 100% of the time. That means by default you can scale the gas limit by three times. You can scale the block limit by three times. If yeah, if that's safe to do, right? And then we can get more execution per block. This benefit both layer ones and layer twos.

And then this also enables shorter slot time in the future because now we can more do more things within a slot, we can have a shorter slot time in the future. And it's worth mentioning this is good with like ZK proving because the bottleneck for a prover today is just the amount of time it has to prepare for a block, right? Because now because of EPBS, now the prover has more time to prove the block. So, this is also good for bringing ZK onto layer one.

The second set of benefit is reliability because of the pipelining because of now the execution block and the blobs are no longer the bottleneck, we should be seeing less reworks, less missed slots on chain. And this is good for beacon chain Ethereum's health in general, right? And then the second thing is that we're less dependent on off-protocol software. For example, we don't have to rely on the relay 100% of the time. We can like rely on more in-protocol software.

And then like clearly accountability when things goes wrong. For example, like if something misses a block, then we'll know who misses a block right away, right? And then the third pillar I would characterize as trust, right? What Ethereum does really good is to minimize trust and this is exactly what we're doing right now. We're minimizing the trust between the proposer and the builder, right? This is the whole like this like this is basically the root of what Ethereum is. And then we're replacing off-protocol like off-chain coordination into more in-protocol rule and that's also good. Last but not least, this enables like more future roadmap that we don't have today that we may want to do one day.

For example, when we want to do MEV burn, we want to burn more ETH such that like we can lower the issuance and this also enables like slot auction, execution ticket more things that's in the future Ethereum roadmap. All right. So, thank you for being here. Thank you for listening to my talk. I just want to mention that this is ongoing. Hopefully, my timeline if you want to ask, this will happen sometime early Q3 in Q3. And but now we have started testing. We have devnets right now. So, if you are a relay, if you're a builder or you were just people that's very interested in this type of

stuff, we're looking always looking for feedback. So, you can join our devnet and start playing with this sincerely. So, thank you. >> [applause] >> So, we will have time for one question. If anyone has a question. Never mind.

Okay. So, there is no question. Thank you. Thank you.