 Today I want to talk about Proposer-Builder Separation, give some updates. In a sense these are updates because it's something we've been working on for some time. I am the team leader of the Robust Incentives Group, which is a research team at the Ethereum Foundation, looking at mechanism design, game theory, economic modeling, these fancy stuff. In the previous episode, let me set a bit of context for what PBS is. Something we definitely have learned to appreciate more in the last years as block space got scarce and as gas fees got more expensive is that we are all learning what block space is capable to do. So when we think of it as an economic good, we try to understand what its properties are, how to sell it and how to provide for it as the protocol, so as the Ethereum protocol. We know that it's valuable. It's the raw material that users take advantage of to do their transactions. But we know also that some of it is more valuable than the rest. For instance, being first to do something or being right behind another transaction, all these things that we call now MEV. That led us to block wars. I'm just going to read from the text here. While the resistance hashtags take from home, solo validators are rookies in the market of galactic proportions. To keep up with the empire, rebels source blocks from distant planets. But the trade is fraught with difficulties. Indeed, because block space is so valuable and because some people got so good at providing it, it has happened, even before proof of stake and proof of work, that parts of the block would be constructed by people who have specific expertise in making the best use of a valuable block space. So we call that MEVGef. This was provided by Flashbox and in this MEVGef network, searchers were these very sophisticated players submit bundles to, at the time, what were trusted block producers, essentially mining pools who were producing the blocks. So these bundles are very valuable, but at the time that the searchers submit them, they don't want anyone to see them because the value of a block could easily be copied by a malicious block producer, which is why the network relied on only trusted block producers. When the block producers receive the bundles, they're scored, they may be combined with one another. Essentially, you're trying to get the most juice out of the scarce block space that you are providing as a block producer. So how does that look today in proof of stake? It looks very empty because I'll add more to it, but today you have essentially two options. There could be more in the future. You could decide to forego this smart network of capable block builders and build your block locally, just grabbing transactions from your local main pool. So in proof of stake, the clients are divided in two. There's the consensus client and the execution engine. You're just listening passively to user transactions and including them into your block. Or you can summon this much more complex external network that involves many parties. So let's talk a bit about them. I'll go from right to left, as I feel this is probably the more intuitive way to go about it. So users send their transactions, their public, they're broadcasted around the network. The searchers pick up some of these transactions and make these valuable bundles. They forward these bundles to builders, and builders are responsible for making whole blocks, and these whole blocks are then forwarded to relays. And the relays act as middlemen in this market between proposers who are the bonded validators in proof of stake and builders. Why we need this intermediary is again because these opportunities that searchers found, they're kind of private. And so we don't want to reveal them too soon to the block producer. We need to make sure that we have a commitment that the block producer will use the block provided to them by the builder before the block is actually revealed publicly. So the relay is this custodian in this system. Mave Boost is a little piece of software that you can run next to your node so that you talk to this network of relays, and once the relay says, I have a very juicy block for you. If you use it, I will pay you a certain amount of if. You sign that block, or you sign that block header as a block proposal via this builder API. With more detail on this, we can really separate it in three phases. The first phase is the bidding phase, where the builders send their full blocks to the relays. The relays have to validate that the block is valid, that there's no consensus error, and that indeed the bid that the builder declares corresponds to the value of the block. In the second phase, the bid selection, the proposer listens to these streams of bids from the relays. By default, today Mave Boost selects the highest bid that the proposer has received. And at that time, the proposer signs the bid with the builder API, and they can no longer make another block. They don't know the full content of their block, but if they were to make another block themselves, now they would have signed two different objects, and they could be slashed for it. In the third phase, the relay receives the signed bid from the proposer, and at this stage, it's confident that it can release the block to the rest of the network, and there's not going to be a copy that is being made. A few numbers that I got from a few days ago, more and more validators seem to choose to use this external block building facility, which today lives pretty much totally out of the protocol. 50% as of, I think that was Saturday. FlashBots still operates the dominant relay, so 83% of the blocks which are received and signed by proposers have been relayed by FlashBots, and there seems to be seven active relays. Some of them are all run by the same entity, and they satisfy different trade-offs that the block proposers may have when they want to summon this external network. So what is PBS? This was sort of an intro. In what I described before, you can think of this as PBS. PBS is more of a philosophy, so it's proposer-builder separation, and it's the idea that as the protocol gets more complex and as the roles of block proposers become more valuable, it may not be possible for the block proposer to do everything, and so parts of what the block proposer does could be outsourced to third parties outside of the protocol. These days, I think of PBS as kind of two different things that we've maybe wrongly put together. So I call it the proposer-builder separation. On the first side, I think of PBS as a market structure or a way of organizing the duties of the proposer with respect to the protocol. So again, there are duties that the block proposer, especially the average block proposer who's taking from home, can't or won't do. For instance, making these execution blocks that contain the valuable block space. In the future, making dunk-sharding blocks, which will contain a lot of data and require very high bandwidth to propagate. Maybe even further into the future, once we have statelessness computing the block witness, if we want stateless block proposers that might not be possible for them. And even further, we might require validity proofs along with the execution block to show that the execution is correct. So that would rely on enshrining some ZK EVM into the protocol. And so it seems to me that the protocol is becoming more and more complex, making more and more things to the proposer. And so maybe it's a good idea to think of ways that we can organize these markets. The second half of the separation is not really the organizing principle, but it's really the shape of the market. So I think of the first half a bit as the legal system. It defines who are the players, and the second half is more of a business logic. What exactly is being sold, and what are the contracts that the proposer enters into with these third parties. For PBS, when it comes to the execution block and block space, the allocation mechanism is a whole block auction. So the proposer sells off their entire rights to make a block. The current design allocates the right to make the exact block to such a third party, as we've seen in MevBoost. Being a bit more precise about it, MevBoost, the allocation mechanism again is this whole block auction, and the market structure of MevBoost places the relays as kind of brokers these deals between the proposer and between the builders. The relay, we expect them to guarantee the validity of the good, but they're not protocol actors, and they could fail. These are a few ways that they could fail. For instance, they could receive a block from a builder and fail to properly validate that it's a valid block. This has happened before. The relay could also not validate properly that the bid made by the builder actually corresponds to what is being paid to the proposer, and it could also fail midway into the deal, and, for instance, deliver the block late or not at all, in which case the proposer doesn't have the opportunity to propose the block themselves and misses out on some of the rewards. So this is kind of the idea of in-protocol PBS is moving this systemic part of the system into the protocol. So in the in-protocol PBS design, the protocol becomes the broker, and it's the one that guarantees that if deals go south, the proposer is still compensated for it. So the builder, in this case, whenever they make a bid, that bid is binding, even if they deliver an invalid block or if they don't deliver it at all. They would have to pay the proposer up to the bid that they have made. So a bit more detail on this. Again, we can use the same framework or division to understand this market. In the bidding phase, the proposers send directly the bid to the proposer. For instance, there's a couple here, five, seven, eight, if. At the bid selection phase, which is slot one, the proposer selects a bid and makes a bid-on block that commits to the bid, which you can see in green below. So seeing this, once the proposer makes a bid, so this is part of the consensus rule, whenever the proposer makes a block, you have a row of attestors, which is a very large set of stakers who vote to say we've seen this block and this block should belong to the chain. So these attestors, they give weight to the bid-on block and they make safe the block in a way that the builder sees it and the builder says, well, there's no real way for the proposer to go back on their commitment to my bid now and so I feel confident that I can release my block and it's not going to be reverted and stolen. That's slot two. At the delivery stage, the builder releases the builder block that contains the payload. So you have a row of attestors that makes the builder block safe. Right now, what I describe is really the vanilla version of in-protocol PBS, but of course, you may, as a proposer, your only value may not be you just want to maximize the amount of e that you get and you might want to add some constraints over the block that is being made so that you don't entirely remove your input from the block production. One way to do so is inclusion lists. So an inclusion list is a list of transactions that the block builder must either include or show that they couldn't include in the block that they made. And the only way that they can't include the transaction is if the block is full. So if you're trying to keep a transaction away from a block over, let's say, a long period of time, it becomes increasingly difficult to do so, and expensive. The reason is EIP 1559. In Ethereum today, if the block is full, it's a mandated base price increasing exponentially over time. So if you want to keep censoring something, you have to keep making full blocks and it becomes just impossibly expensive to do so. So that's the idea behind inclusion lists. Another way to do it is to just let the proposer make part of the block. So for instance, they could do the prefix or the suffix, and they could let the builder build the rest of the block. Designs exist for both sides. If the proposer makes the prefix, the builder will make the suffix, and vice versa. So that's another way to reintroduce a bit of proposer input into the block construction. The third variant of PBS is the slot auction. So I didn't really specify what the bids were, but there are two versions. In one version, the builder has to commit to a certain block before they make the bid. And in this version, the builder doesn't have to commit. When the time comes, I will make a block for you, and you can just select me because I will pay you the most. And so this might be more flexible, especially when it comes to things like cross-domain MEV, which require you to do things just in time. So we have these three variants. They're not incompatible with one another. It's just a matter of deciding the trade-offs and what fits well into the protocol. And even for each variant, I think there's a bit more margin for us or a bit more parameters that we can tune. So if we do a partial block auction, we can decide which part. If we do inclusion lists, you have some leeway on deciding who makes the inclusion list and when. And if you auction the slot, you can even tell yourself that the slot could be auctioned much more in advance than just the current block. So I've been trying to think, maybe adversely, with respect to this PBS proposal, and tell myself, well, if PBS is really two things, a market structure and an allocation mechanism, could we enshrine into protocol only the market structure and let people determine the allocation mechanism that they prefer? So this is a proposal I recently posted on e-research, but it's very new, so I won't talk about it today. Okay, I want to pull out the frame a bit and look ahead to what might a world with PBS look like. So the first question that I guess we ask ourselves a lot as protocol designers is, putting things into protocol is really hard, and if we do that and then people don't use it, there's not really the use for all this overhead. And so the first question, which I think is natural, is would, if we had this in protocol, PBS would proposal use it. One reason why they might not want to is because they could still strike deals of chain with builders and get the builder blocks included, even though they receive beads on some kind of official gossip channel for the beads. There's another proposal, which is called MEV Smoothing. It's a mechanism that takes the block value and smooths it across all the stakers in the protocol rather than giving it only to the current block producer. That would make it binding because it would force proposers to accept the highest bead received on this official bead channel. But there's more questions there in terms of incentive compatibility that I think we need to look at. Another question is, would relays still exist? I've been talking about this official bead channel. There's questions on how to design that. It could still be the case that proposers would listen to out of protocol beads that come from relays that they prefer. For instance, relays might be very good at getting you the best bead very fast in time, or they might be constraining the beads, for instance, with censorship. So as a proposer, if there are transactions you don't want to include, you could listen to some relays that provide you beads with respect to that. Some builders may even prefer to use MEV Boosts since they don't need to put the upfront capital, but it's to the proposers' risk in that case. What does the protocol see? It's a question we asked ourselves when we introduced EIP 1559, and the answer was, well, it prices the congestion in the network. It prices the value that the next person who isn't included would be ready to pay to get included. And as we add more of this economic mechanism in the protocol, we find that the protocol gets more introspection about what happens and the value that people using the protocol get out of it. And so one reasonable question is, what does the PBS bead value exactly? And I think ideally that bead should be the total extractable value that the proposer's position confers to the proposer. But is it, in reality, will the PBS bead really represent this extractable value? Can it be achieved with a single builder? Can it be achieved with a distributed builder? There's more models, I think, that we can work out on this. Another way to think about it is, might the PBS bead be the spot price of value for the block? For instance, if there's economic value from selling the rights way in advance before your slot so that people can plan for it and possibly make promises in advance with the PBS bead, we're not really capturing that. Or is there economic value to selling rights to multiple builders at the same time? So these are, I think, some of the questions with respect to PBS. Putting the frame even larger, and especially in this world where more and more of these proposer duties are performed by third parties or by builders, is where should the Ethereum as a protocol, where should the concern stop? So we could decide that if proposers don't want to do the things that they are told to do by the protocol and if they want to enter into these third party relationships, the protocol can't prevent them from doing so but doesn't have to actively help them either. For instance, we could keep including more things into the builder API at the client level just so that the communication can happen between the proposers and these third parties but call it a day and let the out-of-protocol markets develop there. We could decide to draw the boundary a little further. So this is the distinction I was making. We could decide to say, well, the protocol should guarantee the market structure for the proposers because that makes them safe and it backstops certain bad cases, for instance, relay failure but it doesn't have to determine all the mechanisms. So my Pepsi proposal is in that direction. And then we could also decide that, well, all the markets that the protocol requires for these third party relationships, they should be determined at protocol level and we should be able to find the best way for these markets to organize. At the moment, I think I'm still exploring all options and I think we all are. But as the protocol ossifies, it might be more and more difficult to say for sure that we got it right the first time around and that it's still right 50 years later. Some incomplete ways to think about it. I think these are really the criteria that help us decide between these questions. And the first is what is the risk for the protocol? So if there is a very systemic dependency on this third party relationship, does that put the protocol safety, liveness or throughput properties in J-Party? When we do things at protocol level, does it maximize welfare? For instance, increasing capacity, serving more user transactions. That's a no-brainer for sure. This gets us more value into the system as long as, of course, safety and liveness are preserved. So these things are good. This is maybe a hot take, but I've been seeing, well, if you have boost, you are selling off your whole rights. Maybe we should go back to a world where proposers have to make the block themselves. But I'm not making this argument entirely either. I think sometimes outsourcing things to third parties, it might be good. There might be much more incentive alignment when the third party really wants something to go into the protocol. So there's also that to weigh in the scale. The final thing that we might consider is the risk for the proposers themselves. So I think the protocol backstop possibly risky behavior that the proposer engages in. So yeah, I'm asking more questions than I have answers for, but this is also what's, I think, interesting in the research. I'm not alone in asking these questions. There's going to be much more talks about PBS at DEF CON, and I definitely encourage you to check some of these out. And if you think these are interesting questions, I would also like to invite you to apply to our research team as we are currently looking for someone with a strong research background who knows mechanism design and really loves it and wants to help us make sense of all of it. Thank you for your time.