The MEVconomics of bridging - James Prestwich

foreign [Applause] [Music] yes I'm going to be talking about uh a specific mitigation within the context of bridging I think I was required by Tina to put the word metaconomics in the title of the talk so uh what we're really going to be talking about is using the structure of a bridge and partially ordering messages in order to mitigate MAV and the question context so I'm James I've been working on bridging and Mev since late 2017 early 2018. I've been around the block a few times uh you can find me on Twitter and GitHub all right generally speaking when we talk about a bridge we're talking about two one-way communication channels between blockchains you know from chain a to chain b and a separate system to go back from chain B to chain n the general pattern that these work in is chain a will dispatch a message some off-chain actors will pick up that message and deliver it to chain B chain B will do authentication and validation of the message and then deliver it to the application that receives it and handles it so if you put it on a timeline it looks a little bit more like this each of these steps is atomic on chain or takes a very tiny amount of off-chain time and then there's these big big and computer time gaps between the actions uh you know if it sometimes takes tens of seconds for a off-chain actor to pick up a transaction from the blockchain or they might wait several minutes for it to finalize in the proof of stake consensus though these like gaps between the origination of a message and it's handling by the Astro actors can be emitted and the gap between the off-chain actors getting the message and its confirmation and receiving shipping can be several minutes as well uh as we probably know Mev is a result of uh you know time gaps between committing to what you want to do and that being executed it's a result of people being able to insert reorder or sandwich your transactions after you've committed before their process and so cross chain bridging has a lot of opportunity for Mev to sneak in because there is such a long time Gap from the perspective of each chain so Mev in a sense is about early access to information and cross-chain bridging like that information is published so long before it gets acted on on the remote chain so everyone has you know 10 minutes of warning on what this message does and what it's going to do when it hits the road chain and how to front run that message most effectively so from the perspective of the remote chain the receiving chain a message at a txr equivalent the message comes into the chain someone off chain submits it and it kicks off some events of computation or smart contract running or whatever so a message in a transaction can be be included in the block essentially the same as transactions reordering and sandwiching for questioning messages work just the same but again you have 10 minutes advanced warning instead of seconds so Nev pushes The Ordering of a blockchain towards the maximally extractable ordering the ordering in the block which provides the most value to the Searcher Builder proposer supply chain so everything gets shuffled Envy transactions get inserted and the proposer ends up making a bunch of money so what we want to do is mitigate the impact that reordering and sandwiching have on cross-chain messages because cross-chain messages are more vulnerable than the average transaction so if we're going to change the message flow a little bit that I talked about earlier rather than immediately dispatching to the uh to the other chain we're going to accumulate on the first chain on the sending chain a batch of messages and this should be a batch of messages that touches the same application or the same state and rather than committing key to each individual message we want to get commit to a batch uh so you take all of your cross-chain messages and you put them into a single unit uh and then you dispatch that batch and process the batch on the other end so what does this get us as a mechanism why do this at all uh when you are extracting value from the remote change block ordering putting it in a batch preserves the relative ordering of those messages it prevents the minor or the Searcher or whoever from extracting value by reordering the batch and it prevents the you know Searcher from extracting value by inserting within the batch so this they change to the semantic message handling of the bridge that mitigates the ability to extract energy by preventing insertion and reordering or specific transactions and we do this by changing the bridge and the way it handles messages this usually introduces a small amount of latency but as a result you can't be extracted from as easily so we can extend this to reorder batches upon receipt so when a bat fits the remote chain the destination we can reorder that back on chain using a deterministic but difficult to predict ordering this can be as simple as just shuffling based on the Block hash of the destination chain usually you don't want to use a block hash for entropy because it is in some sense predictable and manipulatable however we're not trying to prevent manipulation we're trying to make it more expensive so what this does is uh instead of delivering all messages in the order they were dispatched you can shuffle all the messages using pretty bad Randomness and then make sure that the messages are delivered in the shuffled order and you might be thinking can't a Searcher just continually reshuffle until they get a good ordering that's more abstractable and yeah they can but you know we have a word for that it's called proof of work so the Searcher now has to iteratively repeat thumb Shuffle hash function and then try to extract upon that blog and it has to repeat that many times trying to find the best shuffling uh and so searching on these shuffled batches becomes a proof of work problem uh it increases the cost to the Searcher in a way that uh mitigates the amount of Mev that the Searcher can extract it is less profitable to do this because the batches can be shuffled by the remote chain and because all we're trying to do is increase the cost we don't need good Randomness to do so we can rely on bad Randomness that the search might be able to manipulate because manipulating the randomness is equivalent to doing the proof of work it increases the cost of extraction so there are a few pros and cons straight offs to this it's easy to implement and very little on chain overhead it mitigates specific extraction from cross-chain messages uh like I said it's the Band-Aid we're increasing the cost we're not preventing it it's a mitigation not a fix and in order to be effective it requires significant throughput if all of the messages touch state then shuffling the order has no effect on the outcomes this only works if you have several messages a significant number that touched the same state so that shuffling changes the outcome of those messages uh the other like major con is that some applications want a specific ordering they want to know that messages are received in the order they're dispatched and this does not preserve that property so this is kind of a quick doodle on potential bridging mechanisms for I mean the mitigation it is not a full solution and it does not work for every use case but it's still interesting and fun to think about so that brings me about to the end of my slides there are a few things that I wanted to talk about but this is a very short time slot so I'm not going to get to one of the things I wanted to say is that cross chain mbv is almost exclusively statistic limit it has a risk involved because it plays out over multiple transactions and Mev is the cosmic background radiation in Cross chain comes and that it is going from everywhere to everywhere all at once every chain is being statistically armed against every other chain in our brief sex at the same time uh but you can't use that communication to carry any useful message uh I really wanted to make a joke about ordering discretion and ordering indiscretion so when you're ordering a block you have discretion and Tina politely asked me to say the word met economics towards the end of the talk so this is me saying the word meconomics and that is the end of my slides awesome thank you very much for that um I think we have a minute before sriram is coming on uh something vaguely related I'm curious for your take on the kind of conversation around it's been a lot in the last week about Roll-Ups and bridges are they really defined by the ridge or is the role of this completely separate thing from the bridge and it's all just chains communicating with each other so this is something that I fight about a lot uh a Roll-Ups like definitionally includes a bridge to the layer one the question that we cite up about is whether the bridge determines the correct state of the roll-up or whether the nodes determine the correct state of the roll up and I land very firmly on the Node side of things uh I think that the bridge cannot force the nodes to accept any invalid block but the nodes can force the bridge to accept at anything and as a result I think that the nodes decide what the state of a roll-up is right in the context of no keep going sorry oh I can keep talking if we're still waiting uh I'm really good at having opinions in the in the context of bridging in this sense uh Roll-Ups are special because they have this built-in bridge and roll ups are a subclass of sovereign Roll-Ups which is a roll-up without that built-in Bridge so you take the Sovereign roll-up you add an enshrined bridge and you have a roll up uh we just came up with the terminology for these backwards so the terminology is a little funky Sovereign type roll ups are the specialized type of the built-in Bridge um awesome Witness just in time he threw him did just join the room uh since we are running a few minutes behind we will go over to him uh really appreciate the talk this was great as always um and we are now going to bring out true on for the next talk and he will be talking about restating an MAV thank you