#DappCon22 : Day 2 - Proof of Steak - How to remooove MEV, Anna George

Transcript

and she will be talking about proof of stake how to remove [Music] [Applause] good hi everyone thank you for being here is it working um thanks for being here um so because the merge is coming up literally tomorrow I decided to dedicate today's talk on proof of stake and how to remove Mev unfortunately I'm not as good in enhancing it as as the moderator quit and so basically the the presentation consists of two parts and

the first one um I'm going to explain the forces of Mev and proof of stake and specifically the risks that arise from having Mev and the second part of the presentation will talk about design choices that can help to mitigate or reduce at least Mev and specifically dive into cow protocol cool let's start so to understand Mev and proof of stake you actually have to understand first who are the different actors in proof of stake and why in proof of work you had the miners who were responsible to create an Xbox and proof of stake you now have the validators and who can become a validator every one

of you can become a validator and all you have to do is basically you have to stake 32 either and then you have to operate a node and also run an execution and consensus client and that's pretty much all you have to do um who house then selected um who will become the validator to create the next block and this is completely randomly picked but there's two things that I want to highlight here one is of course you can increase your chances by running multiple validators so are you restricted by essentially as the amount of ease that you're holding so the more East you have the more validators you can essentially also

operate if you like the second point I want to highlight is that also in proof of stake and this is very different to uh to proof of work um in the time period of an Epoch you actually know who will become the next validators so you can know in advance not only who is creating the next book but also who's creating the next few blocks so what happens now if one of the actors of one of the validators is able to extract Mev significantly better than anyone else from the validators there would over time be able to increase more and more the rewards that are getting because by not only getting the reward for being a validator but

also by extracting value and they're getting more rewards than everyone else and um what happens then they take over a larger share of the network and that's obviously not great the centralization risk because validators are the ones who can send their transactions they can specifically decide what kind of transactions are going to be part of the next block and decide on excluding some if they want to and so obviously these centralization of this valid data set is not a good idea so the question is how can we mitigate this risk and the answer to this is proposal Builder separation

it is something that was two two talks ago actually just presented also by by staff from the flashbots team and um for those who didn't attend the talk we will quickly sum it up again what the proposal Builder separation actually means it means that the role of the validators is being split now into two different actors you still have the validator that is proposing the next block but now you have also Builders entering the game who can compete on deciding um basically what transaction payload should be part of the next block so they basically look at the mempool and maybe private transactions and come up with a

set of transactions and Order of those um to design the next block execution payload and so the validator is selling this block space and the builders are competing by offering bids and how much they want to pay the validated for their blog to be picked so the question is is this now really um solving the problem of centralization and the answer is no or at least not really because what happens now is that before you head to centralization risk with the validators but you now shifted this risk over to the builders now it's

essentially the builders who have the um who have to power over basically um competing against each other and deciding on what transaction payload will be included and a risk that arises from this can come from private order flow so essentially if you now have a wallet um that is willing to um to say that they are going to forward the entire transaction flow only to one specific Builder or to a set of Builders then then this Builder arguably has an advantage over other existing Builders because they have a wider range of transaction to to um to include and arguably have better chances of winning

the competition why would a wallet do this for example they could say hey I'm I'm actually getting paid by the Builder so they have a strategic Advantage so they can pay me a little bit for getting my private transaction flow and um at the at the beginning maybe it seems like a good deal for the wallet but what could happen over time is that the Builder gets more and more stronger they take over larger set of the network of basically winning more and more of the competitions and at some point the wallet is almost forced to send a transaction flow still to that same Builder even if it has become in a way a little bit maliciously because they still want the transaction load to be included in the next block so if they

wouldn't include if they wouldn't send their transactions to this Builder they have a high downtime essentially of their transactions not being included in any of the upcoming blocks and yeah and so this is in a way it's a it's a malicious vicious circle um so let's sum up the argument so far um Mev is definitely to some extent a centralizing force and the proposal Builder separation is to some extent mitigating this but it is moving over the um the risk towards the the block Builders so and maybe one additional point we can make here is um that Searchers and block Builders um are really reaping the

benefits of Meb like they are the the two actors that are really like benefiting from Mev and how it's always the case if you have winners um of a competition or like of a game then you also have losers so let's dive in to understand who are actually the The Losers of our competition and to understand this let's look at the Mev supply chain and what I mean by this is essentially what happens with an order from its initial creation and to its final execution and of course you have the users that are basically submitting the transaction in many cases they do this via an application um in many cases the application then

forwards the transaction directly to the mempool in some cases then some Searchers are making use of their transactions um to to extract some Mev and are collaborating with Builders to incorporate these in a certain order in a block and then the builders compete with each other forward and and then the validator picks the block and then finally executes and proposes the block so who had a happy stakeholders of this so we already said that the value that is to some extent are benefiting from us and the builders so the question of who of the two is really benefiting more it's like there's two sides of the arguments you can either argument and uh in the One Direction where you say

theoretically the competition of block Builders should be so high that they are not able to extract much value for themselves because they have to basically pay a high reward to make to the validator to ensure that their block is being picked and in this case the validator is actually the one who's reaping most of the benefits or if you look at this argument with the private transaction flow in that case you could have a scenario where one black Builder has significantly better value that they can extract out of the block significantly better than the second best builder but either have to pay is essentially a tiny amount larger than what the second best builder is able to pay

yeah and searches in a way they can be the same actor as a builder or it is a separated actor that is collaborating with with Builders together but in any ways they pretty much share the rewards that they are making out of Mev and then you have the applications and this is a little bit tricky so I would say I would argue that most of the applications today are neutral they're basically just forwarding the transactions without reaping benefits out of it for themselves they could act maliciously as we already discussed if they decide okay I just sell the transaction flow to a specific builder in that case they would be uh

also some beneficial beneficiaries out of out of the Mev but the only ones who are definitely losing from the Mev competition are the users who are actually the ones who are making sure that the network is being used and they're the ones who are who are really losing to this competition to this game of Mev cool uh now that we have established um what uh are the negative sides of uh the existing MAV supply chain let's now try to understand what a healthy supply chain would actually look like um on the one hand um yeah you you would say that the competition and each and everything is

depth of the supply chain is essentially should have as much competition as possible because the more competition there is the more the price that can be taken out from the user taken away um should Trend more towards Europe and um on the other hand also if you were to decide where the value occurs should be lying you can argue that it should actually really be distributed towards the edges of the supply chain meaning towards the the validators and the users to the validators because they're arguably providing the capital to ensure that the network is secure and to the users because without the users there wouldn't be any transactions in the first place but

I am going to argue that ultimately and it really has the supply chain and would be a supply chain in which the Mev is not extracted from the users in the first place okay and that leads us to the second part of the presentation to Cal protocol and um how car protocol shows a design that is really trying to mitigate the amount of Mev that can be extracted cool and yeah basically again where does cloud product Collide for those who don't know how protocol is a decentralized exchange so it is lying on the application layer and by the design it's purposefully picked and and that sort of supply chain the user should

actually be the ones that are the happy participants cool but how do we achieve this so what happens at uh cow protocol is that the participants the users that are placing a transaction they are only signing an intent to trade and these are all collected in an off-chain order book and then now it becomes really interesting we have the cow batch Builders so to say who look at the existing valid transactions in the order book and then compete with each other but on first side basically you would argue oh this looks very similar to the black Builder competition but we

have two very significant differences number one is the users only sign and intent and this is really important to remember they only sign and intend to trade and the second one is that the um that the objective function for what our Builders are optimizing is very different to the one to that block Builders are optimizing for what we optimize for is the Surplus the utility that is added to the user order trades so in other words the more benefits the better prices our Builders can achieve for our users the more likely they will win the competition so the one person the one Builder that wins

the competition is the one that creates the most value for the users and in the black Builder competition it's the opposite it's basically whoever is able to extract most value from the user is the one that wins the competition okay and how do we actually ensure that um we can keep our cow batch Builders honest and for this it's also very similar proof of stake so um a cow batch Builder that would take some tokens uh once they've done this they can participate in the competition in case they win the competition they get some rewards paid out and in case that they would act maliciously at their stake

would be slashed queer so um looking again where we sit in the entire supply chain or an entire um chain between order creation to final order execution um you have the users they submit the intend to trade it is collected in an off-chain order book The Cow batch servers are competing to find the best solution the one that finds the best solution basically meaning finding the best prices for the users is the one that wins and then they execute the transaction on chain and now I also want to highlight two things here um if they if once that the cow Builder

has one and is responsible for Trend submitting the transaction on chain the user price the is secured because now if any negative externalities would happen like Mev it is actually taken from the cow Builder but the price that was provided to the user is secured and the reason why we think this is the right thing to do is because you you cannot expect an average user to be professional and knowing what's the best way to submit transactions on chain but the cowboy does their specialized parties to know exactly how to deal with the Unchained environment and they can they know exactly what to do to do to ensure that your transaction is safe

and the second part um is basically that in an ideal scenario there is not even any value to be extracted from your trades and this is where we get back to the point that the orders that you submit are just signed and tense so I'm looking at this example of this graph for example you see that there's two people who are both more or less around the same time submitting orders you have one who is wanting to sell either for die and another one who's wanting to sell die for Isa so they're not matching a hundred percent right because one person wants to buy two thousand die the other one only wants to sell 1900 but 95 of this trade you are able to match directly against each

other so that means you only have a leftover of 100 die that you would actually have to execute via an Unchained amm interaction and what the servers then do they are able to create a single ethereum transaction and put all the different intents from the users together into one single transaction quit and from having these um having users only sign a transaction brings a few additional Price benefits like ux benefits to the users so you don't only have the protection against Mev you also have protection against fat transaction costs they don't have to pay for it they can submit orders without having to spend any ease and um also and one of

the other benefits that come from the site is that for example you don't have to stick to a specific execution path and that for example is very helpful in the context of DOW trading so doubt for doubts usually it takes a bit longer until they collect all the signatures to ensure that their execution that their trade is executed and by the time that they would be ready in many cases the Unchained price point has changed the initial transaction route that was found at time of initial order creation is not the best one anymore but they would be stuck with it or it might even fail and in our case we can always adjust the best uh execution right route in the moment of order execution cool yeah and that is basically the the power behind

proof of stake and that's it [Applause] we've got about seven minutes for questions these people will probably just ask for another move thanks so much for uh your talk it was really interesting

um here I am so my question is um you had one flow chart where it showed user transactions going into the Cal protocol and then those were going into blocks being built um and you have that trophy right so does that mean that that block was the most profitable for validators or for users and you know I guess my secondary question is um if you're competing with other block builders that are sending value to the validators how are you going to get included on chain if it's not as valuable right so thanks cool let's let's focus on the first question where you're asking about the competition between the batch block

Builders like the cow Builders or the why they pick a specific block Builder um so just the cow builders on the right side okay yeah that that is really optimized so basically they are submitting their execution route and basically what they're submitting is this is like the Surplus that we can generate for X Y and Z orders and then there's a competition that's comparing which one of them is finding overall the at the maximum Surplus that can be given to the users and this is the one that would be picked gotcha so like the second stages it gets proposed to the network right validators so you have you have then the one that wins the wins the batch competition

right and this one is then responsible to submit the transactions on chain and then your second question you have a second question well I guess I guess I'm just thinking like if if this is maximizing user value instead of the validator value um and validators want to make the most they can um aren't the validators gonna pick you know perhaps not the cow uh protocol yeah yeah exactly so that's a super interesting question and I think there's like different answers to this so first of all what is done right now and I think what a lot of the service Tuesday is doing submit via flashbus protect

which will now be map boost essentially so they are paying in order to be included and um and then the question is how could there for example afford paying for this in usually we are able to generate a lot of surplus for our users like in one example where um you have someone being able to be matched directly against each other they save also on gas costs because you don't have to individually send the order on chain they're also save on reduced slippage that they incur then they don't have to pay the protocol fees for interacting with unison for example so there's a lot of additional servers that is generated for the users and it also I would arguably would if servers would

have to pay a little bit more in order to ensure that transactions are included in the next block on chain give them a little bit of leeway to use that to pay for this extra additional cost without taking it away from the users hi I have two questions after the presentation so the first one is you mentioned currently the transactions are being batched so does that cause a latency problem second uh sorry let's start with the first one I forgot the second one cool okay so

actually that's also very good question we currently wait for 30 seconds um for um to basically in order that's the first order for the next batch is writing up to 30 seconds to be included in the next batch competition so in that way yes it is creating some latency however we are able this is completely flexible so you once we have more orders we will definitely reduce the time and would probably um reduce us down up to 12 seconds so it is equivalent with the with the block time and proof of stake perfect I'm uh the second question just came to mind so they are different kind of aggregators currently on the market searching the best route so what exactly

is the secret sauce cow protocol to offer the best pricing thank you so what we do is essentially we call ourselves in a way the meta decks aggregator because we are able to send or not as we have to solve this competition right of the batch Builder so we have 10 different ones I think at the moment they're operating and they all have different strategies and it's completely up to them what kind of strategies they choose some of them are actually choosing to check their apis from one inch from password from matcha and um basically follow that execution path so the in the worst case scenario we would offer prices that are that are on par with whatever the other Dex aggregators are offering but in a better case

scenario we are able to match you as part of one of these like peer-to-peer trades and then we can generate better prices on top and on top of that we are also protecting the user against Mev and so on so there's also already now some there's even your ex perks right now trading on cow swap even if you would not be part of a peer-to-peer trade yeah I had a question so I understand the the concept of uh you know how it works for an exchange but what about applications that are not exchanges is there a uh do you guys also have ideas how to expand that to other non-exchange applications basically I'm

I mean that's a super end of Mev that is currently extracted on ECM is actually from Dex trades so we should cover a big chunk of um the problem at the moment um I don't personally like this is definitely something to explore I think there is a lot of room for Innovation for other applications as well but the biggest problem definitely is with dexas and this is what we focus on at the moment I'd say that probably about wraps it up thank you very much