#DappCon22 : Day 2 - Will The Market Fix MEV? Köppelmann, Luhn, Leupold, Gosselin
DappCon 2022 · September 2022 · 29:57
Köppelmann, Luhn, Leupold, and Gosselin debate whether the market alone can fix MEV at DappCon 2022. The panel weighs market-based mitigations for maximal extractable value against protocol-level interventions like proposer-builder separation, a live question for Ethereum's proof-of-stake validators.
Speakers
Topics
From DappCon 2022, hosted by Dappcon Berlin.
Transcript
so the first question is do we need to fix what maybe so um I feel like technically that covers what code for the call Network so what's what's the problem um also by answering the question no the market is not going to fix iMed social consensus well thanks to any of you um maybe we'll see uh but yeah the problem so you know I think flash plus as a company was
founded basically to answer this question right like what is Mev what is the problem that causes to block chains like if there's going to be a chance for us to tackle it like probably it requires an organization that's exclusively focused on this challenge um and we've sort of tried to as deliberately as possible design an organization that's directed towards uh uh trying to answer and solve and solve this problem I think from like a technical level the areas that we are particularly interested in looking at right now the problem areas I guess from an Mev perspective one of them is order flow and my talk earlier was sort of covering that the second one is cross domain Mev and then the final one in my opinion is going to be latency and
latency is to be sort of the the big um the big challenge that that's going to rear it's had its ugly head in the future um and uh if we find solutions for each of these three uh key problems then uh probably Mev will be nearly solved I I'd say those are kind of domains but in what extent are those those problems so kind of what what is a what is the situation we don't want to end up with or whatever right I skipped I skipped a couple a couple uh logical steps there so so the problem with centralization right the problem is that um you end up through Mev having returns to scale in a way that you get super linear value relative to your
share of the network and therefore you're able to compound into controlling more and more of the network um you know this Mev supply chain that that I often talk about once you dominate a single level of it you have an incentive to integrate vertically up the supply chain and control more of the network there's just a lot of things in Mev that leads towards uh natural monopolies and natural monopolies means centralization means censorship means all kinds of other problems so the problem is you know centralized centralization the solution is decentralization yeah I would go even further and say well I mean that's one way to look at it from the ethereum side of things what is the risk to ethereum and I agree centralization is an existential risk to Me Maybe is like the biggest problem we can face on the on
the layer one um today at Cal swap we usually try to take the view of more the trader or use user perspective and there the problem really is Mev is a tax on your activities on well chain and so if we want ethereum to become the global settlement layer for most of our financial activity or even non-financial activity then we need to fix Mev in order for it to be a viable system for everyday users to use the system and so Mev has a tax on on usage and trading for us is the problem that we would like the market to fix yeah I'm sorry I have to agree with both of them mostly also with Felix that uses don't get as much out of their transactions as they should be because
miners or validators are extracting this mvv and we should improve the situation for these users often the users also don't know about this so it's very hard to for them to quantify how much they actually lose but maybe to add another thing um it's also a bit of a problem for application developers so in some sense Mev is helpful it can be used as a tool for application developers but they also have to consider another um kind of as another attack Vector in some cases so that's maybe another problem that applications become more complicated to implement if we if we agree that kind of the the consensus was around centralization is is the main issue I think then we should further
specify uh what is being centralized and kind of one of the questions or maybe critiques I have is uh to say um we don't want to centralize validators I think that that's that's really here we don't want to have kind of just two or three entities but to what extent and that's that's my my yeah to what extent are we fine with uh then centralizing um other roles so I mean concretely in this Builder proposal separation in a way yes we might then have more validators but those have yeah potentially less responsibility uh so kind of
how do you see that yeah do you want to decentralize every single piece as much as possible um Builder centralization is is uh is a risk it's a problem I think the more centralized Builders end up being the more power that they have over the rest of the network um the more that they can do in theory with PBS they can't really affect protocol rules right they can't just decide to Fork on their own because they need to convince a bunch of different violators to Fork but you know a centralized Builder that's dominating the network producing the most valuable block can kind of bribe people to like Implement protocol level changes
um and so like while the structure of the market itself doesn't mean that this party is going to have Direct Control they can have economic control and that can be like sufficient and not change so um yeah you want to you're on this decentralize every bit yeah I think the um I guess and you said it in your talk about it also anas talk basically what PBS does it moves the the centralization um interface of facade one layer back and and maybe there are solutions of how we can move it even further back now the focus I also understand from the flashbots team is to actually decentralize the Builder role at Cal protocol we actually have one entity which is somewhat similar to the Builder and it was part of Anna's presentation
we have these solvers the the relayers that compete for the user's order flow not in the form of transactions but in form of trade intents and we have actually spent the last six months trying to decentralize that role um just after the the spin-off car protocol has launched an incentive program for external solvers to come online at the time there was only uh solvers they were operated by gnosis doing the matching at this point today we have five external entities in production right now and we're trying to we're working with five more parties roughly so we're hoping to have 10 external solvers in production by the end of the day and I think kind of the the join Journey we went through there with decentralizing this critical road to the protocol is something that hopefully we'll see in PBS as well and maybe we can work together with
flashbots or whoever is is is working on these building these Builders eventually Cloud protocol might want to become a builder themselves as well um but yeah I think I totally agree that we need to decentralize all these roles and I think our protocol has shown in the last six months that it's that is possible so I'm fairly optimistic on given the right set of you know fundamentals having a low barrier to entry having a permissionless system and kind of all these things that are required there um that that this is possible My worry is that if we have two mechanisms kind of competing against one another and one is specifically more you know profitable for one party in the network let's say the the validators of the builders there might be some some forces that or some
collusion at stake that that will prevent these more user-friendly and and I would say overall better Market mechanisms to take prevalence as we have seen in traditional Finance where I guess exchanges have also dominated the choice of mechanism for for traditional financing but um yeah that's maybe going a bit far I have a follow-up question what is sufficient decentralization of the Builder rule yeah it's a it's a good question um so for sure it has to I guess one one decentralization aspect is also how easy is it to join in case you see something going south right like if you were seeing like there's there was the socket mevd which I thought was interesting that also looked at scent um censorship from two different angles one is like
temporary censorship where maybe your transaction sort of getting mined in the next block it may get mined in two or three or four or five blocks Which is less of a bad censorship than if you're actually banned from the network and you're not going to get mined at any point in time and so for decentralization I think um you know if you if you want to throw a number at me I guess it also depends on the mechanism it depends to the level of collusion that's necessary to attack the mechanism if it's one third fifty percent two-thirds um at cow protocol right now we're aiming for uh you know 10 10 solvers by the end of the year I think that's that's an ambitious goal if that's sufficient I I you know I I wouldn't I wouldn't be confident on confident saying that um I think eventually it would be nice
to have builders that you can spin up on demand kind of if you run adapt node you have like a package that says okay I have like a you know standard Builder that is ethically compliant with what I want and I can run it and and spin it up if in case I feel like the the system's not healthy or see like this uh yeah we had this talk about vitalik as well if we feel there's a consensus attack then making it easy for everyone in the network to to participate is kind of key there okay some of the things I picked up on there was like censorship resistance and collusion resistance are kind of like two big metrics to look at from a decentralization point is that yeah yeah okay are there others I think other things you tell me do you think there's other
things no well uh I no to me I think those are the main things but it's so okay I think one thing might be security of the network so you want to validate many lots of validators because if you have lots of validators you have lots of stake and that increases the security of your protocol yeah I mean do you see there is a role or is is there a role for yeah regular steak at home super small builders steak at home no I mean I mean but I mean I mean like is is there a road and I want a builder at home or I mean like
um steak at home so kind of you have 32 Easter and that's it but you're building your own blocks is there a role for for oh I see um without relying on like Outsourcing the block Construction um probably not probably not I think the open question is like how commoditized is block building going to be right like is it going to be the algorithm is open source and like we know what the optimal construction looks like the order flow is like universally accessible and there isn't like the problem of of exclusive order flow and like really the only problem with um with operating a builder is the same
as operating a validator which is you want to be on a performance machine and keep it online um if we get to that point with block Builders I think you know we'll be in a really good place um but there's a lot of different things to solve before we're able to determine if that's you know where things are going do you guys think uh the public mempool as we know it or as we used to Know It uh will will continue to exist Ure I hope so um because the alternative is private mempools and private mempools are I think susceptible for uh to censorship because it means that your transaction is only seen by a few parties whereas if you send it to a public member basically
everyone sees it and everyone has the option to include it yeah I also I also feel like we have to keep the existence of the private of the public member alive otherwise we are not building a better system than what traditional Finance has built and actually uh one thing that I that I that I sometimes think about when I see this Mev supply chain graph from a user has an intent submits it to the wallet the wallet submits a transaction to the Builder and the Builder submits a block to to the validator I kind of you know overlay the traditional Finance when you have your account at your broker your broker is selling your order flow your broker is basically your wallet your wallet is selling your order flow to a wholesaler or like a market maker hedge fund which is basically your Searcher or
your builder in this case and then that that entity is is forwarding Your settlement and actually doing uh whatever t plus two settlement with one of these clearinghouses and then I feel like wow okay so we've rebuilt the traditional Finance settlement flow in in defy and uh 50 seconds instead of two days no I mean that's that's that's that's that's great but yeah I mean there's this this quote by Matt Levine that deep is a frequently or blockchain in general is frequently just Reinventing 100 Years of financial history and I feel like sometimes when I see this this chart I'm like wow okay this is this is us Reinventing a traditional Finance so what is different is there anything different or are we just uh there isn't regulatory capture yet really
I don't think so um so what is different um I think what's different is like the people that are in this room the people that are in our community like talk about these problems openly and publicly and care about maintaining a decentralization of the system I don't think that this is something that ever existed in traditional Finance like when a lot of these electronic trading systems got developed in the like late 90s early 2000s it wasn't like everyone knew they was going to get digitized and it was gonna like have these centralization effect and these like market makers were going to become dominant like you couldn't really predict that
um people were just trying to do things that they thought would make the market more efficient right like hey maybe if we just like take all these traders that are like running around Wall Street and like screaming at each other and like replace them with a computer like the markets will be better um and so you know they were trying to improve things I think now we have like this incredible opportunity where like we see how that played out we see sort of the Dynamics of the market structures that evolved out of it um and we have the tools to be able to create Alternatives and and explore Alternatives um so for as long as I think there's a community and and there's like this social consensus this social belief in wanting to improve um uh the way things are um then we we still have a chance to
change it um about the the transaction pool question that you asked earlier um I don't think that the transaction pool as we know it today is going to stick around um and I don't think that that's a bad thing either um I think it's a bad thing if it gets replaced by something that doesn't add additional value but in my talk earlier I sort of looked at okay well what does a good order flow system look like and the transaction pool was sort of mediocre on all of my criterias so I think that it will be seceded or are you know it will be replaced by something that's materially better better I don't know exactly what that is and there's probably a bunch of trade-offs involved in the design but it will evolve to be
something different yeah I mean but maybe just again to paint the picture of what could happen I guess in the in the worst case in the worst case uh wallets would yeah essentially directly send their transactions AKA orders to maybe just one Builder and then of course that Builder well we'll almost always win win the blocks because they uh well have additional additional order flow and maybe they can uh they can yeah kind of offer something to the users so they continue uh to do that but again it has this very very severe
um centralization Force yeah maybe the other aspect for why the public map which can actually continue to exist is that I'm I'm personally quite hopeful that we can actually reduce the amount of Mev that we Expose and use those transactions and and the only reason we need these private mempools is for yeah for transactions that are prone to Mev and I think there's been some research already done I think we can do much more to to actually build Market mechanisms that reduce the amount of Mev of course there's still the question what will we do with the leftover um I'm still positive that all or most types of MAV can actually be addressed at the at the dab layer or at least the the distribution can already be kind of
enshrined into into the depth layer I think one worry that I might have and and I think that's that's kind of where will the market fix Mev is if these kind of mechanisms even if they were proposed and implemented would they would they would they get to adoption and if not would it be just on a user experience level or would it be could it be potentially be even on a level that Builders said well this is a mechanism that eats my lunch I'm not going to mine transactions that are using this protocol because it's trying to prevent Mev and so that to me is the the the Market Force fear that I have which would be similar to what happened in traditional Finance uh not willing to implement batch auctions for example because uh you can get a lot of money from collocation
um and yeah Will the Market fix Mev by actually letting the best and user protected protocols exist and when that is maybe a segue to yeah something you have been working on maybe you can describe um what exactly okay Beacon chain yeah yeah basically the mechanism is um uh Felix says the goal is to reduce me view that might be one one good thing to do and one way to do is using to use encryption if your transaction is encrypted you don't expose all the information that your transaction contains to uh to the person who includes it in a block so they can't extract the mov basically and ideally that mbv stays for yourself and only after the transactions is included in
the chain then it will be decrypted um yeah that's one approach that's independent of the application there it can be done for all kinds of transactions but um and it has some advantages but also some disadvantages what do you see are the chances that kind of those more fundamental changes will be done on protocol level I personally think that one really nice advantage of PBS is that we can actually experiment with all these different types of um of pro of kind of well Builder models in a way we can have uh pay for order flow Builder we could have a we could have a shutterized builder we could have a cow Builder like we can actually without prior to committing to what is
the best layer one solution to Mev experiment with some of them and well hoping that the market doesn't get screwed or or prevents the best run from winning could yeah experiment at a faster Pace than if we were to do the research now and had to pick one up front yeah we had actually this conversation privately uh earlier and I think actually it's probably not on the Builder level that you do different strategies but on the proposal level maybe you couldn't expand on that or yeah I mean the Builder is not a perfect abstraction um there's still a bunch of powers that like remain with the proposers um I think I mean one fear that I have is that flashbots becomes like
us like it slows down Innovation on mitigations and it sort of becomes like um a gatekeeper on deployment of of Novel solutions that can help Target some of these uh these gnarly problems um and I think like the Boost abstraction is good like it achieves the the stated outcomes that that it has but I don't think it's like the perfect solution um and so if we get into a world where like this becomes a new default and you're stuck into only building things on top of it because nothing else is going to end up being adopted um I think that's materially worse for for the ecosystem I'm like I'm pretty optimistic about layer twos and
alternative chains um implementing some of these other tools so that we like see a counter factual right like what is an alternative um deployment using like a similar evm you know type structure uh end up doing to the Meb Market on those chains I think there's a lot of room for for iteration on that front and yeah and as much as it's possible to combine different techniques like what shutterized block building plus Outsource block building Through Math boost I think there's there's a lot of benefit to it so yeah yeah the point I was just trying to make why I think it's on the proposal
level and not necessarily the Builder level is that math boost essentially says okay I'm now a proposer and I'm I'm just kind of kind of asking many Builders and and take uh who's who's bidding the most but I don't actually care about the strategy there could be an alternative solution where I as a proposers I do kind of commit to a specific strategy and probably that would only make sense for for larger uh kind of validators but if you are well in exchange or one of those I mean even rocket pool light or whatever and you have let's say 10 15 of of the staking power you could say on the blocks I propose I'm using a strategy other than kind of just selling it to the higher
highest bidder instead let's say I just do um yeah real-time transaction ordering so as transactions come in I commit to to to to to do this exact in that sequence and potentially people are willing to then pay an extra fee to specifically submit their transactions in a block um that's such a proposal um is doing and I guess yeah right speaking chain could be one strategy for such a proposal yeah but why wouldn't you implement such a mechanism at the Builder level um well I think the Builder can give way
less guarantees so as a proposer you can give a strong guarantee that well you will propose it as a builder you can only say well I'm using this strategy but it's quite likely that another Builder will out-compete me on this on this block another way to say is like if the proposer is only communicating with one builder then you can do it but if they're profit switching between multiple different ones then you have some execution risks that you have to model in yeah but I guess the proposal could commit to only using like if they want to do this Choice then it might be easier to just pick a builder that does the job for them I mean so fair enough so so kind of no I think yeah it's possible on both sides so kind of if you only submit your transaction for example
to a specific Builder that commits to a specific strategy then you might also not care whether they but eventually maybe they will will get a block where where they are picked and as long uh those transactions essentially stay private within within that Builder so yeah you're right cool can we open it up uh oh yeah for for questions I have a question I think um please so what on on the transactional level we talked about like privacy being like a direction that things can go are there
other like features or uh innovations that like are low hanging fruits for the transaction level um yeah kind of a broad question but I'm curious I guess your escalation or escalator model that would it's a long low hanging fruit and it also seems very useful oh I think there are plenty so I I mean once one thing I would love to see is that you make transactions that are valid um or where you can define a few well kind of storage slots or state and it's only the transaction is valid um or the transaction is only valid if that storage slot is uh has has a
specific value and then you could even go a step further and say you can create a transaction that appends a pending uh transaction so kind of well one obvious use case would be more efficient uh back running in a way but another use case could be that you essentially built already those those chains of transactions which could also quite help for parallelization yes I'm very excited about that as well I I think I mean personally I would I would actually prefer most of these Innovations happen on the intent level again going back to your Mev supply chain you have the user that has an intent of what they want to do and it
doesn't you know ethereum transactions are a pretty heavyweight thing to change and adjust it will take months or years to make a change to that to that structure to that model and and create a hard Fork whereas on the on the user intent level if we can get dapps to care more about what does the user want sign what you want and not how exactly you want to achieve that we can have a lot of things like well I want given that as the concern that is the the state I want to do this like basically you can yeah you can you can I think encode a lot of these things we talked also about um your the Dutch auction that you're proposing could be done on a depth level where you basically say here's my limit price currently and then it goes over time it will will go down as I'm not
getting settled I would prefer we do a lot of things on the intent level because there we can already do stuff like batching people together saving on gas costs which ideally should then also affect the the Mev footprint of the depth and yeah do some other things that are just not possible on the transaction level unless we do really really heavy redesigns of the protocol what do you think is missing to be able to do things at the attend level um maybe some more account abstraction on what you can on meta transaction basically what you can execute on behalf of the user I think there's also a lot of things we can do on the depth level like tokens having Erp 2612 the permit
signature implemented for example um and then I think it's it's generally user awareness and kind of re-educating users that's signing a message is as powerful as signing a transactions as a transaction but actually a better user experience right now there's still kind of this I guess you know would actually want to hear from other adapts what what are the problems that we've heard from our users that they are not used to signing a message and and therefore they're a bit like what am I doing is the safe um you know why don't I assign a transaction and maybe it's just really a user education issue at this point and I would say kind of one more thing could be a standard forms to broadcast those trading things so kind of a regular transaction you can put into the mempool maybe that's going away but at least
it's it's working uh pretty reliably uh for for that kind of signed message this intend it's not clear where to put it so flashbot's Discord usually sorry flashbots Discord I tried I I put in my censorship detection contract in there and no one picked it out for a very very very little very little people well let's catch the side side story so yeah the censorship resistance or censorship is is a real problem so yeah I created this tiny tiny contract that you can ping every hour it will pay you two dollars or it will pay you simply kind of what you spend in gas but pay
double it back um but it also sends one way to the git coin address of the tornado team which is on a specific list so uh it was kind of just a small exercise to see whether whether this contract gets called um and yeah kind of on flashlight level that that's such a transaction would currently get excluded yeah so we've got time for one last short question right here do you think it makes sense to have a two-tiered product with different fee structures whether the user would like to opt in for an atomization or not
what's good where the users would like to opt in or out of um having the option of Optima anonymization like a two-tier product opt-in to what feature and an anonymity yeah uh or just like privacy well some similar to a mixer like which is different from what it does right now I'm not sure I follow sorry I think we may have to save this question for off chain if that's all right with everyone we're out of time thank you all for an excellent thank you thank you