Extracting MEV After the Merge / Lightclient

Transcript

foreign good morning everyone I am really excited to be here to give an overview of how Mev extraction will look after the merge so to do that there's a couple things I want to talk about first I want to give an overview of how we're doing Mev extraction today and then some of the problems of taking this system and directly applying this on top of what we have today with the post-emerge world

and then I'll give it an actual overview of what the extraction will look like with a set of validators rather than Miners and then just talk about some of the future research that we need to do in this space to get to the ideal world that we would like to be living in so to recap today we have these entities called Searchers and Searchers are just people who are watching all these public and private transaction flows that exist looking for transactions that have some sort of value that they can extract and once they find this value they connect to a builder and bundle a transaction that they've created with the

transaction that's vulnerable and they submit these to the builders and the builders take these transactions and they bundle them into a block and they share this block with the miners and then the miners perform their proof of work seal on top of this block and eventually they find a seal release that block to the network extending the Chain by one and then the cycle repeats and hopefully this cycle was happening in parallel with multiple Builders so you have some Searchers connected to one Builder some Searchers connect to another Builder they're all sharing blocks it's an open market looking for the block that has the most mov in it so if we look at the relationships that exist between these different entities

we have first this relationship of the Searcher and the Builder this tends to be a one-to-one relationship so you have often one Searcher connected with one Builder we have the Builder and the miner and the Builder is trusting that the miner won't steal their transactions and then we have the minor and the minor is just receiving all the these kind of pre-computed blocks and just doing the proof of work on top of it so this first relationship sort of checks out because it's a one-to-one relationship and if you're searching for Mev and you've only connected to uh to one block Builder and you've only given your transaction to one block Builder you have a pretty good idea when your

Mev is stolen and if you see that a builder is stealing your nav it's very easy for you to just use a different Builder um for the builders it's a little bit more difficult because they're actually sending their blocks to multiple miners but we have this assumption that Builders are much more sophisticated and much larger and have the ability to play iterated games with the miners to sort of deduce which Miner might be stealing their Mev so we can still say that this relationship is okay and then miners receive everything in the clear so they don't need to trust anyone and we can just say that this is this is fine merger we apply this exact same relationship we get the same thing we

just replace the concept of miners with validators and the first one continues to check out we still have that relationship there's one Searcher connecting to one Builder but now the second one is where things get a little bit more interesting and to determine if this relationship makes sense we need to think about this formula and this relationship actually only makes sense when this formula does not uh return true and so this is basically saying that the expected value of the relationship that the validator has with the builder needs to be less than the Mev that can be extracted in the block because if the Mev that you can extract in the block is actually more valuable than your relationship with your Builder it's a rational actor

will simply steal the Mev that the Builder has given them and so this doesn't work and just applying this old system that we used to pre-emerge falls apart once we start having blocks with large amounts of Mev so if we zoom in on this equality we can see that there's kind of two ways to go we either need to reduce the amount of nav in a block or we need to increase the expected value of the relationship of the validators with the builders and if you know much about Mev it's pretty difficult to try and control Mev so that's sort of out we can't reduce the amount of Mev that exists in a block so what we could do is we could actually increase the expected value of the

relationship between the Builder and the validator and the way that we would do that is we would say you need to send me some signature of 10 of your validators or 100 of your validators whatever the expected value that we're looking for to make sense they need to prove that they have control of that much stake this is basically increasing the capital requirements to be a part of this system and this is kind of what we're doing today with mining pools because mining pools the expected value of their relationship with the builders is very high if they were to steal Mev from from a builder and get cut out of the Mev Network then that would be extremely detrimental to their future profits and so we can kind of do the same thing in

the staking world so you have a large Staker they're the only ones who can connect to this this Mev Network and the small at home Staker is not able to unfortunately over time the large Staker starts accumulating more stake per stake that they have versus the at-home Staker and then they eventually dilute the at-home Staker to almost nothing so simply increasing the capital requirements of extracting Mev doesn't really work and we need to think of a different solution and this all really stems from this statement that Builders are trusting the validators to not steal and what we really need to do is think about a different way of of approaching this

problem and one thing that we can do is we can just flip the trust so rather than the validator being The Trusted party the the formatting error with PowerPoint the validator now is the is the non-trusted party they are doing the trust with the Builder and so they're now trusting that the Builder will reveal the transactions rather than being the party that's being trusted and this is kind of what we've done with this external Builder Network and this is this is a protocol that we have defined at this GitHub repository if you want to take a look and see exactly what it looks like that's the place but we'll do an overview in a moment

this is all work that actually has stemmed from the flashbots team so mid last year Steph from The Flash Watch Team wrote this post on ethereum Research called Mev boost merge ready flashboss architecture and a lot of the ideas that went into that post are seen in the protocol that we have today with this external Builder Network so a lot of the credit is really due to like the work that the flashbots team did last year and they continue to do throughout the beginning of this year so the full walkthrough of what the external Builder Network looks like it starts first with the validator who's about to propose a block they say Builder please give me a execution payload header

and the Builder receives the request and the Builder behind the scenes is constantly looking for the next block in the network kind of like they do today they have the searches sending the transactions they're aggregating them so when they receive this request they can immediately respond here's an execution payload header the validator takes the execution payload header and it constructs a blinded beacon block and a blinded beacon block is almost exactly the same as the standard beacon block except that you don't have the transaction bodies and if you're familiar with headers in the ethereum one chain it's the exact same concept in the header you only have the root of the transactions so that's the only thing the validator sees and fortunately the way that the

mercurization works for these blocks is that the blinded beacon block route is the exact same as the full beacon block route so they're able to Simply sign this message and send it back to the Builder and say I would like the full beacon block now and they send their signed blind beacon block and this is enough actually to be a accepted consensus message on the beacon chain so they've basically now committed to saying this is the block that I'm going to propose I just don't know what transactions are behind it and then the Builder verifies that that block is signed correctly and everything else checks out and then they reveal the transactions that that were originally blinded and so this is the full flow if you look on the the spec on the GitHub there's a

couple more methods there's a registration method that I didn't talk about but there's a couple things that you need to let the Builder know before that you propose your blog you want to let them know what your the gas limit that you would like them to build as and you need to let them know where to send the fees to we saw mov boost as this idea that Steph proposed last year and in fact it still is around we've just sort of modified the way that it's used in these protocols and so we have simplified the the connection between the builders and the validators but there's still a lot of things that we want to do Beyond just what we went over in that short back and forth between the validator and Builder and so

Mev boost facilitates that and the way to think of Mev boost is it's sort of a multiplexer between your validator and many different Builders and by having this as this external mechanism we have a lot more latitude to be able to add fraud proofs add other mechanisms to search for faults that the builders might have it just gives us a lot more flexibility than constantly putting these into the consensus clients and that isn't even maybe what the end result will be after the merge it's very possible that we have another layer of indirection between the builders and the validators Mev boost clients and this is because it's important that now that the

trust has been put on the builders that we help increase the trust by maybe having you know parties that are known rather than unknown Builders we want to have unknown Builders be able to compete in the open market but that then creates some conflicts of interest because the person with the most amount of money essentially gets to be the next proposer of the block so that's a pretty thorough overview of what the external Builder Network looks like now I'm going to give a short overview of some future research problems related to this network and uh you know the ideal world and that Ideal World is this proposer Builder separation and if you've been following protocol research and development for the last six to

eight months you've probably heard about this concept PBS and PBS is really the ideal world where we have this in protocol separation of these two entities we've done that by using the external Builder Network to have a de facto separation but we don't have the the amount of latitude that we really want to be able to in protocol attribute fault if a builder is you know acting maliciously and this really happens and I'll go in this in a moment with this data withholding problem but it's really important that in protocol we have this mechanism that allows us to have committees that are able to attest to certain behaviors of different actors

and it's difficult to do this in an external network because you have a lot of the same coordination problems that blockchains were built to solve it's also important to note that PBS is a requirement for dank Chardon which most of you probably have heard of and so because dank sharding increases the requirements on the Builders without having the separation between the proposers and the builders that means that we would also have to increase the hardware and bandwidth requirements of the validator set which is something that we would we really don't want to do so PBS is is important for many things in the future not just how Mev is extracted so I mentioned this data withholding

attack this is generally the problem of separating these two things right now everything sort of lives Under One Roof we have the validator building the block and proposing the block there's no coordination of information that needs to happen but once you separate those those things now you have two parties that are trying to have information released to the network and either of them could fail and we need to be able to figure out whose fault it is and so if we look again at this diagram of the flow between the validator and the Builder imagine everything goes just as we had mentioned a few slides prior except on this last one the validator asks for the full beacon block to be revealed to them that way that they can

publish this message to the network and the entire chain can move forward but the Builder doesn't respond and when the Builder doesn't respond there's no way for the validator to prove that it was the it was the builder that didn't respond because the Builder can simply just say I never heard from the validator and now it's just the Builder's word versus the validator's word and this is what we really need to avoid and in in protocol PBS allows us to do this with these committees but this external Builder Network we don't really have that concept yet and so now you know just this communication between the validator and the Builder this is susceptible to this data withholding and so maybe we added some sort of committee that lives

external to the network similar to how it would be in the PBS world where the validator sends all of its messages through the committee and to the Builder that way the majority of the committee if they check off and say I saw this information then we have a even better idea of whether or not that information was actually revealed and when the Builder doesn't respond either to the validator or to the committee the committee can now attest with high confidence and say I never heard from the Builder and you know whatever this protocol defines to happen whether it's slash the Builder disconnect from the Builder that can happen now with a higher degree of trust rather than relying on the words of one entity or another

so a few resources if this is interesting for you the block construction channel on The Ether D Discord is kind of where a lot of the chatter is happening right now the Builder specs is sort of the canonical specification of this protocol that that I went over and then we have two implementations of MAV boost one by the flashbots team and one by Alex Stokes um if you're interested in some of the more research problems then Mev boost the flashbots metal boost repository has a lot of really interesting issues that talk about more existential threats to these systems so I recommend checking that out and maybe discussing some of those things there

thank you [Applause] questions okay um that finished a little earlier than I was expecting but we are good for questions now yeah I was curious so why shouldn't the Builder simply bribe proposers to order for Mev sorry so if the Builder knows the bribe or knows some of the so yeah the Builder knows the proposers are going to sequence the Block in some way why shouldn't the Builder just black market bribe the proposer to sequence the Block in a order that's favorable for the Builder

I mean that's basically what they're doing with this like separation like the the builders are bidding there are many Builders happening and they're bidding to try and get the validator to propose their block is that what you're referring to so the the the build there's multiple Builders and so each of these Builders are submitting a bid into this network saying I bid you know one eth for you to include mine I bid 1.1 eth and so it's kind of an open market for Builders to decide and so if you go through a back Channel you still kind of need to compete with that open market as well there's definitely the ability to do a back Channel because this is not enshrined in any protocol that's totally

fair game and possible and especially possible with very large entities they may you know have their own separate Network that's separate from this but if there is an open market it's likely that that's the you know the going price for Block inclusion okay another question here are two three four uh okay good so uh you were talking about the data withholding problem right I'm wondering why you chose to like consider that the main problem why isn't the problem the fact that the validator is actually signing a Blog without knowing what is exactly in that book because imagine that I'm a builder and I say you know

Screw all those proposers there is a really good nft drop happening right now so I'm just going to stuff the block with transactions that I'm mining this nft over and over and over for myself right I blind it I send it to the validator validator says okay I guess this is good Mev because you know somewhere there I will have received some value sign it send it back to the Builder Builder you know doesn't even reveal anything to the validator it just broadcast it to the network because it's already signed and the validator has sorry the Builder has all the data and suddenly we have kind of propagated it blocked through the network that the validator would have probably never signed if they saw that it contains garbage like that so isn't that a bigger

problem and how are you solving that with the design that you're proposing yeah there's a lot to unpack there but the signature that I don't know my slides are gone the signature that they're signing when they sign the blinded is the exact same consensus message so like you said once the Builder receives that the Builder can immediately disseminate that to the network and honestly that's the most likely thing to happen because there's a lot of value for the Builder of that block going out and so there's nothing that the validator can do at that point like they don't know what the transactions were and so they just included it and now we're starting to get into this question like how much energy should the validator put into like determining like a you know a fair block like with transactions that

shouldn't like fairly be included but kind of the way that we've accepted is a fair block is the block that pays the most that was like sort of the simplest thing and because we have that open market of bidding for Block space the Builder who bids the most you know if that happens that they mine all these nft transactions and that's valuable enough to them to pay more than anyone else that's the block that's going to be propagated and that's kind of similar to to today but you did mention another interesting thing about why are we focusing on the data withholding problem is the worst problem and I do think that is like a good question and of itself because there are a lot of other problems that might exist like you can imagine if the validator doesn't know what transactions they're submitting they might sign a block that's invalid

right and that's a big problem but the thing with that problem is is that because the Builder signed the bid we have a cryptographic link between them signing an invalid block and we could automate some sort of fraud proof for proving that but it's very easy to prove cryptographically with the data withholding attack that's not attributable and that's why to me that's the worst thing that can happen in this system sure okay another question from the middle hello uh so uh I was wondering when you started the presentation that this inequality between the expected value and the uh

and the value of the relationship it somehow flips because we're moving from proof of work to proof of stake so why is that happening so what's the qualitative difference between now and the possible post-merge world right so the equality the expected value of the relationship between I say the validator in my slides because we're referring to the Val the validators post merge but you can also think of the equality today and the uh you know actor would be the the miners and so if the expected value of the relationship between the miners and the builders were competing with the value of Mev per block we would have a similar problem but because the mining

pools are so powerful there's you know it's only a handful that are producing the vast majority of blocks and they're extracting Mev from all of these blocks if they were to lose out on that that would be a non-negligible part of the amount of profit that they're taking in right now and so the expected value of that relationship is very high if they were to lose out on that order flow that transaction flow from the Builder that would you know this is a very bad thing for them and so it's not that they were necessarily like flipping it it's just we're increasing the number of at-home block producers today like de facto ethereum only has you know a handful of people who are truly producing blocks after the merge we now have you know hundreds thousands tens of thousands of

people like truly producing blocks and so that's why that sort of flips after the merge okay there were some questions from before have they been answered now okay then I think we're done here thank you very much like Lion thank you [Applause]