Towards Enshrined Proposer-Builder Separation

Transcript

foreign [Music] hello hello okay sounds like it's on hey everyone I'll let these people get seated cool hello everyone my name is Mike neuter I work at the ethereum foundation I'm also I'm a lady and today I'll be talking about uh towards and Shrine proposal Builder separation which is the project I've been working on over the past few months uh yeah just wanted to shout out the the EF folks that that are in the crowd and have been helping tunnel with this

project as well as the the core devs and the relay Community like all of this is is a product of our collaboration so yeah quick outline of what I'll be talking about we'll go through what proposal Builder separation is we'll talk about Mev boost which is an out of protocol implementation of PBS uh that's the acronym we we typically use to talk about proposalability separation we'll talk about enshrining PBS which is the process of bringing the the actual mechanism into the consensus layer of the protocol we'll talk about why we want to enshrine it a few different designs we're discussing including two slot PBS and the payload timeliness committee and lastly we'll talk about optimistic relaying which is

an iteration on the current map boost relays that that starts to evolve the the mechanism in place to look something like in trying PBS with without all of the overhead of actually bringing it into the consensus layer so that's what we're going to be going through I'll start off with just kind of the etymology of PBS so the first time it was mentioned I think was this post in vitalik from June 2021 and so this was even a year before the merge and the idea here is that proposers who are the validators selected to propose a block during a slot these are the proof of stake elected validators and this is supposed to be the the decentralized set of of the ethereum protocol so they should be

unsophisticated they should be able to run on relatively low powered Hardware kind of at-home stakers we want to be able to support and this is kind of a different ver this is a different set of people than the builders who are the participants who are actually capable of constructing the super high value blocks and in this in this context high value blocks just means they're able to extract lots of Mev from the blocks and the reason this is a sophisticated thing is it might involve some complicated simulation many different arbitrages across pools it might involve having liquidity on a centralized exchange to to be able to do Arbitrage there so these these actors are going to have um kind of by definition be be a lot

more sophisticated and have higher requirements for running them and so the idea is to decouple the two roles of proposing the block and actually constructing the block and this will allow for for more decentralization overall because if we didn't kind of formalize this relationship between these two entities then you could imagine a world where large staking pools have kind of out-of-band relationships with Builders because the builders are able to produce better blocks and and in that world the the solo Staker that home Staker has no way to essentially earn the same rewards that they would in a pool so the ultimate goal here is to kind of expose this this process of of block building

and block construction to the everyday at home Staker cool so well that was kind of the intro quickly we'll talk about Mev boost which is an out of protocol proposal Builder separation implementation uh map boost is built by flashbots and it was designed by them and launched with with the merge and the key new entity that that's defined here is this relay so the relay essentially acts as a trust broker or a mutually trusted Auctioneer between the proposer and the Builder so the there's a few trust assumptions going on the first is that the Builder trusts the relay not to steal their Mev so a relay will have access to the Builder block

before the block goes on chain so the relay could in theory copy those transactions unbundle them and and take away some of the Mev from the Builder so the Builder has to trust the relay not to do that the trust assumption from the proposer is that the relay will provide them a valid header to sign and the reason for that is is the Builder sends the full blocks to the relay but the relay only forwards on the headers of those blocks to the proposers so the proposer is kind of signing signing a header site unseen and they're trusting that the relay will give them and publish a block that actually ends up on chain because they're signing something that they that they haven't been able to fully verify and the way this this works is the the validators run some side card software

called nav boost it's used to interact with the relays the relays are their own implementations that are running in in quite resource intensive ways and the the builders are kind of isolated from the proposers and only communicate through the relay and I guess the the tldr of the Boost is that it it has massive adoption right after the merge kind of immediately it jumped up to about 90 uh market share and and now it's up to 95 so almost all ethereum blocks are built through the relay and Through Math boost in general and the reason for that is quite simple it's that proposers who who use nav boost will earn a lot more than if they built their blocks locally and again this kind of goes back to the fact that that

extracting Mev is is quite a complicated process and Builders are highly specialized at that so allowing them to do that um is is something that the proposers want to do because their blocks become more valuable cool now we can talk about enshrining PBS and the word enshrining is is kind of vague but really we're just talking about bringing this whole mechanism into the consensus uh the consensus layer and there's a number of reasons we want to do this the kind of clearest one is the fact that relays are are quite against ethereum's core values so there's only about eight relays that are that are active in production only maybe four of them have have double digit

block share so it's really quite a small set of operators um that have have quite a lot of control over the network it's also a vector for censorship um so immediately basically because the relay executes this auction they get to decide which blocks qualify as as valid in this auction and what this allows them to do is if if a block includes transactions that touch and address that's on the sanctions list for example they could just disqualify that block from the auction altogether and when the ofact sanctions happened that's essentially what took place some of the relays implemented these kind of ban lists and any any transactions any blocks that included transactions touching those addresses were censored

and lastly the trustlessness property is is kind of taken away so because there's only eight entities it kind of works today where proposers are able to trust those those relays and Builders just the relays too because there's relatively little overhead in that and the the relay reputation matters a lot in that regard so yeah those are some of the issues with the the kind of value alignment of relays additionally out of protocol software is just painfully brittle so there's been a few high-profile incidents lately I would say the first being the low carb Crusader attack where a malicious validator exploited a relay bug and they were able to essentially steal 20

million dollars worth of a different sandwich a different sandwich Bots liquidity and that was that was kind of a relay vulnerability but it also affected the consensus layer and so not great the chappella bug was an issue with prism where they're externally built block signature generation had a bug in it so immediately post chappella there was some amount of missed slots mainly because those those signatures were all invalid and additionally there's just High coordination costs here so the execution layer clients and the consensus layer clients have a very kind of a very well specified Cadence of specs and and hard forks and producing producing software upgrades whereas the

MAV boost and the med boost relay are kind of more ad hoc they're they're kind of usually thought of as secondary like kind of second-class citizens in in the overall spec and as a result um they the implementations for the for the hard Works usually come quite late in in the development process and just generally add a lot of overhead to to everyone's life and lastly relays are just quite expensive the bar plot on the right shows the cost of running the ultrasound relay this is kind of the estimated cost for a Year's worth of of operations and this is just the infrastructure cost so it's around 70 to 80 000 Euros and that doesn't include you know devops any software

maintenance any additional overhead of managing such a important piece of infrastructure and also there's there's just no clear funding model so the relays currently are are operating as as peer Public Utilities a few of them are being run by by companies that are trying to monetize in different ways but for the most part it's it's basically just a money pit essentially so yeah that's that's kind of motivating why we want to get rid of these relays and in trining PBS is just the means to that end and yeah I guess I'll go through a few of the designs so the original design was presented by vitalik in October 2021 and it's it's kind of a

a very simple but but clean solution to the problem and what he proposed is we spit we split one slot of today into two slots of of this PBS version and the first slot would have these things called Beacon blocks this is kind of the block that we know and love of today and it includes a commitment to a builder bid this is kind of the same as the um what the what the relay is doing just in an actual beacon block and there's one round of attestations that happens after the beacon block deadline and then the second block that's produced is this intermediate block which actually contains the execution block body so this is the actual list of transactions this will update the execution layer state and this will also be attested too by

the remainder of the attestation of the testing committee for that slot so in the original post he proposed that one of the subcommittees votes for the beacon block while n minus one vote for the intermediate block but you could partition the testing Committee in a number of ways and the Builder block is is basically given first class status in this in this model because they get full attestation weight on their block and this is what kind of raises the issue and and motivated us to think about different designs is that the fact that the Builder block has basically full rights of a proposal block means that some of the security properties especially around reorgs are weakened by

by this design so I won't go too much into the details here there's there's more on this if if you want to talk about it but yeah this motivated us to think about alternative designs and this brought us to the payload timeliness committee so this is a very fresh design very much work in progress so it could very well change in in the weeks or months but um yeah some of the themes are similar but there's there's some slight variation to what I described in the two slot version so here we have a consensus layer block this is exactly as as before it has an execution payload header and a builder bid and this kind of carved out portion in the bottom half of the block is where the the payload will show up but before that we have the slot and a testing committee cast their normal lmd

ghost votes for the block so this is exactly as the consensus layers implemented today and eventually the Builder is expected to reveal the execution payload so this is kind of like putting the pieces together of the full block the Builder publishes the payload and now we have the namesake of the design which is the payload timeliness committee we're thinking this could just be a subset of the slot n a testing committee and they cast out of stations basically saying was the payload published on time or not and and this kind of includes it was valid too that's like part of the the validity check that the the payloton is committee executes so the the kind of subtlety here is that

the payload timeliness votes aren't used in the fork Choice rule they're only used to determine if the CL block has an execution payload or not and the reason you need these votes at all is because the subsequent blocks builder needs to know if the execution State changed through the previous block like if the list of transactions actually became part of the canonical chain or if it was an empty block meaning there was no execution payload and you should use the the previous execution layer state so that's the yeah that's what the the kind of differences between this and the the previous design cool so lastly I wanted to talk about optimistic relay so this is kind of a

different approach to the whole process of enshrining PBS and it's it's saying okay let's take advantage of the fact that we already have the relays there's only eight relays that exist we can update their software much easier we maybe can update some of them while leaving others on other versions and we can kind of iteratively work towards and trying PBS by by removing some of the relay responsibilities so if you look at this block submission flow this is kind of what takes place when when a builder sends a block to a relay and there's essentially a lot of steps involved there's the block has to be downloaded it's validated against the execution layer client it's published through the consensus layer client and then it goes to the to the P2P Network so this is kind of inefficient and it also

relies on the relay doing kind of a lot of tasks it's a very heavy process so how can we make this more look like epbs we can kind of take the bottom-up approach and start removing some of the responsibilities of the relay so the first version of this which we call optimistic V1 we just kind of cut out the block validity check so this sounds kind of scary but we um kind of just by doing this we can save about 100 to 200 milliseconds of latency and also it greatly reduces the cost of running a relay because now all of the block simulations that we had to do previously we can do either asynchronously or just skip altogether and we protect the proposers by collateralizing Builders so if a builder

ends up sending a block that wins the auction but doesn't doesn't result in a block on chain then the Builder collateral is used to repay the proposer so that's kind of the new version of the trust assumption is we trust that the that the relay has enough collateral to refund the proposer even if the Builder block wasn't valid and didn't end up on chain you can take this a step further and this is what we call optimistic V2 and what we do here is we actually just cut out the block download altogether so this turns out to be the next part of the bottleneck in terms of network latency and this saves us an additional 50 or 100 milliseconds of latency and yeah the same thing as before we're still collateralized so if the block doesn't download ever then we can we can

use the re uh the collateral to refund the proposer in the same way we did before and I'm running a lot of time here so I'll just wrap quickly the end game of this optimistic relaying thing starts to look a lot more like the payload Timeless committee so here we have the Builder and the proposer interacting directly through the P2P layer so the builders are sending bids to the P2P the proposer publishes the signed header and then the Builder publishes the block and here the only role of the relay is to kind of monitor what's happening in the P2P in the mempool and and a test basically to the timeliness of different events that took place and so this this makes the relay like extremely lightweight they just need a view of the mempool and it makes the

relay kind of behave a lot like the payload timeliness committee so it allows us to to use some of the infrastructure to kind of build out the the relationship between the Builder and the proposer and then when it's time we can supplant the relay with the payload timeliness committee and bring it all into the protocol so that's kind of the the long-term merger of the the optimistic relay and the payload timelase committee so just wrapping up um we're dependent on map boost relays that's bad for these reasons and epbs is a way to eliminate that dependency so the kind of top-down approach is starting at the design specking out and and working kind of through the normal all core devs pipeline and we're also working on this bottom-up optimistic relay roadmap where we change

what the relays do and and kind of get closer to what intron PBS should look like so thank you very much happy to take any questions [Applause] so how does the collateral work if you have these Mev rewards that are like 2 million or ridiculously high compared to how much Builders are paying now sure yeah so for the optimistic relaying what we do is we check that the Builder block the bid on that block has to be less than the collateral value so that

kind of restricts the set of blocks that are actually handled in this optimistic way um for epbs this is this is kind of difficult because there's only so much collateral you want Builders to have to put up right um one way you could think about this is you could have the builders put up 32 each and then they could get slashed up to that full amount for for producing an invalid bid um but yeah there's there's other ideas like you could have a kind of a ZK snark that proves that the Builder paid a certain amount through a block without actually revealing the block but these types of things are are more speculative but yeah this is exactly like the type of thing we're thinking through which is like how do these unconditional payments actually get processed especially in in high Mev regimes yeah

great question um just raise your hand if you want to ask the question and we will give you a microphone uh could you explain a bit how the transition to prove like what did this landscape look like before proof of stake with the Mev boost how has it changed and how higher priority do you think this is for the network as a whole sure yeah I'll preface this by saying I wasn't actually here before the March so um but my understanding of how it worked is that there was this software called

Mev Geth which was the original flashbots you know mining sidecar software and this allowed mining pools to to have bundles sent to them from Searchers and so there was kind of a trusted relationship here and that also worked because the the mining pools are are have a reputation and they didn't want to steal Searcher bundles because if they did then the Searchers would no longer send them bundles and and that like immediately reduces their their value so yeah I think in the in the proof of work world it was It was kind of slightly easier because there was so few block producers relative to the like 600 000 validators in in the proof of stake World um but yeah I think as far as priority

goes the the relays are are quite unstable currently there's different discussions going around how to fund them if if some of them might start shutting down if there's no funding model provided so I would say it's quite high priority but I'm a little biased any questions if no more questions thank you [Applause] [Music]