# Updates on Proposer-Builder Separation by Barnabé Monnot | Devcon Bogotá

- Speakers: [Barnabé Monnot](https://streameth.org/speakers/barnabe-monnot)
- Channel: [Devcon](https://streameth.org/devcon)
- Date: 2023-10-07
- Duration: 21:51
- Watch: https://streameth.org/watch/yt-sQQ2UYB3qOI
- YouTube: https://www.youtube.com/watch?v=sQQ2UYB3qOI

## Description

Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on Swarm, IPFS and more.
https://archive.devcon.org/archive/watch/6/updates-on-proposer-builder-separation/

In this talk, I will discuss updates on PBS and economic models for validators, builders, searchers and users.

Speaker(s): Barnabé Monnot
Skill level: Intermediate
Track: Cryptoeconomics
Keywords: proposer builder separation,cryptoeconomics

Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum
Learn more about devcon: https://www.devcon.org/
Learn more about ethereum: https://ethereum.org/ 

Devcon is the Ethereum conference for developers, researchers, thinkers, and makers. 
Devcon 6 was held in Bogotá, Colombia on Oct 11 - 14, 2022.
Devcon is organized and presented by the Ethereum Foundation, with the support of our sponsors. To find out more, please visit https://ethereum.foundation/

## Transcript

foreign [Music] today I want to talk about proposal Builder separation give some updates in a sense Visa update because it's something we've been working on for some time I am the team lead of the robust incentives Group which is a research team at Via theorem 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 blogspace got scarce and has gas fees got more expensive is that we're all learning what blog 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 V 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 was taking proof of work but parts of the block would be constructed by people who have specific expertise in making the best use of a valuable blog space so we call that Mev gef this was provided by flashbots and in this Mev Gap Network Searchers who have 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 they are very valuable but at the time that the Searchers submit them they don't want anyone to see them because the value the value of the block could easily be copied by your malicious block producer which is why the network relied on only trusted block producers when the block producers receive the bundles that's called where may be combined with one another essentially you're trying to get the most juice out of 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 blog locally just grabbing transactions from your local mempool so in proof of stake the con the clients are divided into there's the consensus client and the execution engine you're just listening passively to user transactions and including them into your blog 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 transaction they are public they are 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 vent forward 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 are 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 broad producer will use the block provided to them by the Builder before the block is actually revealed publicly so the relay is viscosed to the end in this system my 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 blog 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 as a Blog proposal via this Builder API a bit more detail on on this we can really separate it in 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 and 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 beat selection The Proposal listens to these streams of Beats from the relays by default to the MAV boost selects the higher speed that the proposal has received and at that time the proposal signs the beat with the builder API and they can no longer make another block they they don't know the full content of their blog 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 bead 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 these external block building facility which today leaves pretty much totally out of the protocol 50 as of I think that was Saturday plus both flashbots still operates the dominant relay so 83 percent of the blocks which are received and signed by proposals have been relayed by flashbots and there seems to be seven active relays some of them are all run by the the same entity and the let's say satisfy different trade-offs that the blog proposals may have when they want to 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 proposal Builder separation and it's the idea that as the protocol gets more complex and has the roles of block proposals become more valuable it may not be possible for the blog proposal to do everything and so parts of what the blog proposal does could be outsourced to to third parties outside of a 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 proposal Builder separation separation on the first side I think of PBS as a market structure or a way of organizing the duties of The Proposal with respect to the protocol so again there are duties that the blog proposal especially the average block proposal who's taking from home can't or won't do for instance making these execution block that contain the valuable block space in the future making dong sharding blocks which will contain a lot of data and require a very high bandwidth to to propagate maybe even further into the future once we have statelessness Computing the block witness if we want stateless blog proposals that might not be possible for them and even further we might require validity proofs along with execution block to show that the execution is correct so that would rely on enshrining some ZK evm into the into the protocol and so it seems to me that the protocol is becoming more and more complex is asking more and more things to the to the proposal 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 is not really the organizing principle but it's really the shape of the market so I think our 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 one of the contracts that the proposal enters into with these third parties today for PBS when it comes to the execution block and block space the allocation mechanism is a whole block auction so the proposal 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 MAV boost being a bit more precise about it may boost the allocation mechanism again is this whole block auction and the market structure of map boost places the relays as kind of brokers who broker these deals between the proposal and between the builders but relay they we expect them to to guarantee the validity of the good but they are not protocol actors and we could fail these are a few ways that they could fail for instance they could receive a Blog from a builder and fail to properly validate that it's a valid block this has happened before we really could also [Music] not validate properly that the bid made by the Builder actually corresponds to what is being paid um to The Proposal and it could also fail Midway into the deal and for instance deliver the block late or not at all in which case the proposal doesn't have the opportunity to to propose the blog 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 a system into the protocol so in the in protocol PBS design the protocol becomes the broker and is the one that guarantees that if deals go south The Proposal is still compensated for it so the Builder in this case whenever we make a bid that bit is binding even if they deliver an invalid block or if they don't deliver it at all they would have to pay the proposal up to the bid that they had made so a bit more detail on this again we can use the same framework or division to to understand this Market in the bidding phase the builders send directly the Beats to the proposer for instance there's a couple here five seven eight if at the beat selection phase which is slot 1 The Proposal selects a bit and makes a beacon block that commits to the bit which you can see in green below so seeing this once the proposal makes a beat so this is part of a consensus rule whenever the proposal makes a block you have a row of a testers 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 with the testers we give weight to the beacon block and we make save the Block in a way that the Builder sees it and the Builder says well there's no real way for the proposal 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 2 at the delivery stage the Builder releases the Builder block that contains the the payload and once again you have a row of attesters 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 proposal 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 list so an inclusion list is a list of transaction that the blog Builder must either include or show that we couldn't include in the blog that we made and the only way that we 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 inexpensive the reason is eip1559 in ethereum today if a block is full the protocol 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 to do so and so that's the idea behind inclusion lists another way to do it is to just let the proposal make part of a block so for instance we could do the prefix of the suffix and we could let the Builder build the rest of the block designs exist for both sides if the proposal makes the prefix the Builder will make the suffix and this vice versa so that's another way to reintroduce a bit of proposal input into the block construction the third variant of PBS is the slot auction so I don't really specify what the beads 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 the address saying when the time comes I will make a Blog for you and 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 free variants and we are not incompatible with one another it's just a matter of deciding you know the trade-offs and and what fits well into the protocol and even for each variant I think there's a bit more 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 path 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 you know this look with the option much more in advance than just the current block so I've been trying to think maybe adversarially with respect to this PBS proposal and and tell myself well if PBS is really two things a market structure and an allocation mechanism would 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 if research but it's it's very new so I won't talk about it today okay I want to pull out the frame a bit and 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 when 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 we might not want to is because we could still strike deals of chain with Builders and get the Builder blocks included even though they receive bids on some kind of official gossip channel for the beats as a novel proposal which is called mev's moving it's a mechanism that takes the block value and Smooths it across all the stickers in the protocol rather than giving it only to the current block producer that would make it binding because it would force proposals to accept the higher speed received on this official B Channel but there's more questions there in terms of incentive compatibility that I think we need to to look at another question is would relays still exist I've been talking about this official beat Channel there's questions on how to design that but it could still be the case that proposal would listen to out of protocol bits that come from relays that we prefer for instance relays might be very good at getting you the the best beat very fast in time or they might be constraining the Beats for instance with censorship so as a proposal if there are transactions you don't want to include you could listen to to some relays that that provide you beat with respect to that some Builders may even prefer to use math boosts since they don't need to put The Upfront Capital well it's to the proposal's risk in that case pulling a little bit more what does the protocol see it's a question we ask ourselves when we introduce the ap1559 and the answer was well it prices the congestion in the network it prices the value when the next person who isn't included would be ready to pay to get included and as we add more of these 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 bid value exactly and I think ideally that bit should be the total extractable value that the proposal's position confers um to The Proposal but is it in reality does the PB will the PBS bid 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 made the PBS bit be the spot price or 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 bid we are not really capturing that or is there economic value to selling rights to multiple Builders at the same time so these are I think very interesting questions with respect to to PBS putting the frame even larger and especially in this world where more and more of these proposal Duties are performed by Third parties or by Builders is where should the ethereums if a room as a protocol where should the concern stop so we could decide that you know if proposal don't want to do the things that they are told to do by the protocol and if they want to enter into this third party relationships well the protocol can't prevent them from doing so but doesn't have to actively help them either for instance we could keep in including more things into the Builder API at the client level just so that the communication can happen between the proposals and these third parties but call it today 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 some kind of Market structure for the proposals 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 to organize I at the moment I'm I think I'm still exploring all options and I think we all are but as a protocol oc5s it might be more and more difficult to say for sure but 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 of a 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 Jeopardy when we do things at protocol level does it maximize welfare for instance increasing capacity serving more user transaction 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 so these things are good this is maybe a hot take but I've been seeing well nav boost you are selling off your whole rights maybe we should go back to a world where proposals 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 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 proposal themselves so should we shoot a protocol backstop possibly risky behavior that the proposal engages in so yeah and asking more questions when I have answers for but this is also what's I think interesting in the in the research I'm not alone in asking these questions there's going to be much more talks about PBS at Defcon and I definitely encourage you to 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