Proposer Builder Separation, Layer 1 R&D - Day 2

[Music] super hi everyone i'm barnabe mono i'm a researcher at the robust incentive group rig today i want to talk about proposal builder separation more specifically i want to really get into why this is a good idea and why we're getting to this point because i think this is maybe the most misunderstood thing about it and then i'll give you some questions to think about at the end to understand pbs we have to kind of understand the history of block space ethereum is a protocol that sells block space but it's also a protocol that secures a lot of digital assets that have value and it means that people who interact with a protocol they're going to adapt their behavior develop market structures that allow them to make better use of that block space some of these market structures they're out of protocol but when they become systemic it might be a good idea to to be proactive and to move these things into protocol and that's kind of a long story of of pbs we've done it before for instance with eip1559 we decided that the addock market that we had was not as optimal as it could be and so we moved some things into the protocol such as pricing and we've seen that you know it provides a net reduction in complexity and and we in fact have many other features that come from that so let's get into why this market is valuable so to understand the market i want to kind of understand what's on the other side so the user side and what they get out of using ethereum so you can think of the user as having some sort of utility for sending a transaction right they have a willingness to pay they have some money that they want to expand and if you're an economist a bit like me you can draw this demand curve right and that's neat with the ip1559 you target the price that equalizes supply and demand it's all good most of the time it is all good but sometimes this fails so this this neat little curve it's actually not what's happening because transactions they can revert so things can happen to your transaction that you don't really expect and then you might not have the same value for these different outcomes for instance if you try to mint an nft while everybody else is meeting it and if you come too late and the contract has run out you'll find blocks that are just filled with reverted transactions from people who couldn't meet the nft in time and so that gives us a clue that the utility of a transaction is actually very much state dependent okay we know when when a user publishes their transaction in the in the transaction pool we know their intent we know what they want to do i want to swap some tokens i want to mint an nft and this intent that is public means that people can see it and they can try to take advantage of it okay so we know that as front running or back running basically there are incentives to exploit either the state that immediately precedes your transaction of a state that immediately succeeds it this has led to the well-known phenomenon of priority gas auctions this is one plot from the flash boys paper that shows bidding bots competing against one another to be the first uh to exploit the transaction and this is kind of bad right the problem of pgas they have a lot of negative externalities because the bots are replacing transactions a lot uh they kind of bloat the transaction pool uh because multiple bots are competing for the same opportunity only one of them eventually wins and and and and makes it into the block but all the others are also in the blog but reverted so this is kind of a waste of valuable block space and three one five five nine in fact they could even be so dramatically increasing their bids that suddenly the oracles would go haywire and tell you that the gas price was really really high but what i want to get at is that we can't think of transaction as atomic any longer we have to think of them as valuable not just for the fact that they are included in the block but also valuable depending on their position and position is really just another way of saying they are valuable because of the state that they act upon and so how can we think about this so we think of them as bundles now so for instance let's say there's a transaction which is an oracle update for instance a price feed and i can exploit that and make a lot of money if i can get my transaction right after the oracle update so the utility for me to send this bundle where my transaction immediately succeeds the oracle update is very high but if somebody else sends their transaction in the meantime and is able to to get between me and the price update then my utility is actually very low so if we want to let users bid on these atomic bundles so saying allowing me to say i really only care if my transaction gets in right after this one it opens the space for a very complicated auction mechanism we call them combinatorial auctions it's it's a kind of auction where i don't really care only about the item but i care about bundles of items this leads to an explosion in complexity and this is why we have searchers who are specialized in finding these opportunities and finding these profitable bundles so the searchers they come at at the end and they say i would like to beat like this bundle is variable for like a million to me so let me give you the block producer nine hundred thousand so that you you include my bundle okay but that's a very complicated market to organize pre-merge in proof-of-work um how this market was organized is basically out of protocol when the searchers send these bundles they literally leak alpha they tell you what's a nice economic opportunity and so there's a risk that by doing that the miner that they send the bundle to exploits the opportunity instead of them so that's a problem we call that pre-confirmation privacy and the solution today is flashbots is basically whitelisting a set of trustworthy miners that won't steal the bundle and so they share these bundles only with miners in that list it's not great but today most miners are mining as part of mining pools so by sending the bundles only to a few key players they can kind of organize this market the mining pools are very identifiable so they can also the users of these pools can apply pressure to say you know flashbots is sending you juicy bundles please share the rewards with us who are mining for your pool but it's still a little brittle it gets even worse in proof of stake so the one nice thing about proof of stake is that we have this long tail of solo validators the reward variance is much lower you can get paid every epoch and so there's not as much economic incentive to join a staking pool but the problem is that we can't wait list everyone right if you're a solo validator you only propose a block every so often which means that you can't really be trusted by your by a third party if we only share the alpha the juicy bundles with trusted validators will quickly get to a point where the system becomes very economically centralized as solo validators would be discouraged and then they would join staking pools one solution to that is to share the bundle header so do blind proposing you commit to including a bundle but you don't know what it is so you commit as a proposer to to include that bundle but now the problem with that it's not really compatible with searchers doing only one part of the block let's say the top part and the proposal then doing the other part if you commit to something that you don't know what it is maybe you're including duplicated transaction at the bottom if you commit to it and then it's revealed to you the proposer then also has time to extract some mv right there's maybe a two-step process where you you see the bundle you know what's inside and now you have a few more seconds to to do more extraction and this is kind of incompatible with making proposals as naive as possible if they have to become sophisticated and if they have to think about these things this is going to centralize and it's going to lead to the bad outcomes that i described previously and so the solution here is to extend the auction say it's no longer bundles now people can give us whole blocks okay and the proposer can simply decide which block to to choose so the builders are now the ones who are proposing these blocks a few disney derata that we want out of this system so the first one is basically that proposers can't steal the builder data right if they see a juicy opportunity they have to commit to not stealing it we have to ensure that the two parties in this market the builders and the proposer they can't grief each other for instance the builder could promise to pay a very high amount and then never reveal the payload making the block invalid which means that the proposer has missed the opportunity to to choose a different block and then proposers should don't also be able to grieve builders by promising that they will include the builder getting paid and then not including the bundle which leads the builder to not receiving that money there is a design to do this post merge which was proposed by flashbots and i just want to run through the steps it's fairly simple but it involves another party which is called the relay so the relay sits between the builders and the proposers the builders first create these blocks and they evaluate how valuable the blocks are to them they say i promise to pay the proposal this amount if i am included and so the relay collects these blocks and these bids after which it sends that to the proposer only the block header so that the proposer cannot see the content of the bundles so the proposer is expected to choose the bid that would give them the most the most money they signed that bid again it's just a header so they don't know what's inside and once the relay receives the signed bid they can basically make the block on behalf of the proposal so the full beacon block with the execution payload at this point the relay could just gossip the block and the proposer couldn't submit something else at risk of being slashed this works but we have now this relay which is outside of the protocol and which is has to be a little bit trusted so there's ways to decentralize that relay but if you have a liveness failure um you you need some sort of fallback mechanism to tell you that okay this relay is offline so now you need to make the blocks yourself as a proposal it's a little tricky to decide when to activate it and it means that we have to rely on this outside party and so we get to pbs this was a long winded way to to get to there but but but i really feel this is the the way to to think about it so now we're trying to make move to the protocol the parts of the system that we believe are systemic uh risk to to this market and so in protocol organize this market for four blocks between builders and proposals at the moment there's a design that seems the most workable it's called the two slot design so in the first slot the proposal sends a beacon block that contains the bid that they plan to include in their block and in the second slot the builder is expected to reveal the exec block body that they constructed the same kind of fork choice is applied to both blocks so that if the body is missing the proposer still gets paid because they have done their part and send the block in slot one and if the builder doesn't reveal oh and if the proposer doesn't commit to something the builder doesn't reveal their block so that then they can't have their contents uh stolen there are many open questions and i hope you can help us figure some of them out at the adversation later the first one is you know it's a it's a big change it it involves a lot of different actors is the mechanism incentive compatible is everyone incentivized to do their role properly for instance would a builder prefer to enter into agreements with a proposal what about the block release timing like if you can game that you can get more mev or more bundles in are there any other deviation a second thing is is the mechanism live so to make this mechanism work we might need and actually a small change to the first choice called block slot where which allows people to vote for saying that they haven't seen something that however imposes a latency constraint because now you have to say well eight seconds have elapsed i haven't seen something i vote that it's not there but but but this latency constraint can maybe be attenuated with something like a like a backup scheme so that whenever the latency on the network gets too big we just increase that that time that we give us to to see something um valuable and then is there better right it's we i think we're still early into the research stage but and there may be different designs that would uh do the job as well there's a proposal by vitalik for instance that looks more like if you were using via testers as the relay um in this flashbox design so yeah different design might exist and then more questions right if we have a single builder because it might be the case that it's such a difficult activity that it centralizes around one builder doing the blocks for everyone in that case how can we guarantee that the protocol is still resistant to censorship it becomes much less costly for the single builder to to not include a transaction so an id by francesco cr list might be a way to force builders to to include transactions that are censored but there's a lot of analysis to to do there as well and generally i think a nice question would be to try and think through what will the market look like are we going to end up with a single builder are we going to have a fierce competition of builders and a very wide market of searchers on the other side um this is in my opinion quite unexplored and it could give us a nice insight to to do this design properly so join our workshop at 11am in expo this room thank you [Music] you