MEV & Interoperability: Rollups, Cross-L2 & Cross-chain

i'm assuming that i'm not going to see myself show up on the zoom call here because i don't know how this works um we can just dive into the panel because it looks like we have most of the panelists here i think the only person i haven't heard from yet is john adler do we know if he's on the call i'm here oh perfect and i can even see you cool um so this panel is about mev in the like coming cross chain world uh we only have about 30 minutes for it and we have five people so i'm going to try to get through the introduction really quickly so we can just dive into questions um i'm james prestwich i'm going to be moderating the panel today i'm lucky enough to have with me uh five people who work on layer twos roll ups and cross chain environments like cosmos and celestia throughout the panel i'm going to be trying to say cross domain uh some of these things are not strictly speaking chains although a lot of the semantics for connecting them are just the same um so whenever i say cross domain communication just think cross chain i'm just trying to be a little more uh technically accurate um so uh i know that each of the panelists has a lot of opinions on the subject i'm gonna give each of them just a minute up front to talk about themselves their project uh and give a brief introduction um could we start with uh zucky cool um so i wear many hats i think in this in this particular domain i'm wearing the cosmos ibc at um uh uh representing what sort of the the live internet blockchain like communicating white clients system of uh of of inter blockchain communication great um john do you want to go next sure hello everyone i'm john adler i'm with celestia labs where i do protocol uh protocol specification and research and i guess i also wear several hats and in this case i guess i have been brought on to talk about things like shared security models when it comes to cross-domain communication ed hi everybody i'm ed felton i'm co-founder and chief scientist at off chain labs and we make arbitrum which is a layer two scaling solution for ethereum ellie elibensasson co-founder and president of starkware we use a zk starks which i call even co-invented with some of my co-founders uh to solve scalability um on start connect and ben hey folks i'm ben uh co-founder of optimism we're building optimistic ethereum and i will similarly take less than my minute a lot of time well done panelists uh we're moving through things quickly um i think it's interesting that we have a split of people you know john and zucky who are working on uh multi-chain environments and other uh like non-ethereum things and we have primarily ethereum based roll-ups which are split between the optimistic with ben and ed and the zk with ellie um so i kind of want to start off by talking about the technology a little bit um for each of you how does your system handle cross-domain communication for the roll-ups how do you communicate with the layer 1 and for cosmos and celestia what does that even mean in your environment and let's go in reverse order can we start with ben you can indeed you can indeed yeah so in layer twos right where we're kind of uh we have this l1 running the show where the data is coming into and disputes are going to be handled if necessary um basically the l1 is that source of truth so the way that we do and so the cross-domain messaging is sort of based in that l1 so we have two kind of levels of cross-domain communication in our system the first is a lower level one um where basic and but the interfaces are very similar and it's about the properties that these two bridges give you so at the lower level you basically have any smart contract or account on layer one can send in a message which specifies a target some data and a gas limit and that will eventually be included as a call in the l2 chain uh or domain i should say and um yep so that so that's what it is and then you have an op code in the l2 vm that lets you access who on l1 set that call so this has there's one tricky part with l2s which is that you can be out of gas and you kind of can't know about it on l1 right because you have to impose a gas limit on l2 and because the whole point is that l2 is a separate environment l1 can't know about it so basically we add an additional layer of messaging which is like really what's exposed to devs which has the same properties but basically wraps everything in a system that enforces atomicity so it might be the case with that lower level message sending that a smart contract might send a message in but on l2 that basically times out beca or can't be run because you're out of gas the chain is too congested at the moment so we add in another layer of messaging that gives you atomicity where if you pass the message in it's guaranteed to be received at some point in the future some point in the future some point that's right so that's kind of the two levels of cross-domain messaging that we have cool and uh let's go to ellie uh how does uh stark um how does the stark based rollups handle uh cross-domain communication so uh currently um um you know we have a few different systems that are live in production and um the the way that there's cross-chain communication right now is basically through layer one and you know and the way you would imagine it you pull something out and you take it in from the other side um so yeah and i like to speak more about you know what we actually have and about what might be in the future um so i mean yeah i'll just stop here you know we'll have better cross-chain communication directly between things but uh you know when it's ready we'll uh we'll be able to discuss it but uh yeah that's the way we do it right now um i think it's uh for for people who might not be aware how many different production systems is stock we're running right now currently we're running three production systems spot trading it's a diversified dydx does uh margin trading or perpetuals and just one second and uh i'm at home with my kids um and uh uh immutable x does uh minting and trading with nft is also a third party so so they have a whole ecosystem running there you know and um very soon sorry is going to go live uh which is gonna be another uh nft based thing so you know three right now in a few weeks for um yeah very cool um ed same question uh how is arbitrary handling uh communication with the l1 sure so some people will use specialized cross-domain functionalities like cross-chain atomic swaps and so on that would work pretty much across any pair of chains but the general purpose cross domain communication and call mechanism we use is basically one that allows a contract that's running on one chain to send a call to the other chain so that's call data call value and a destination and because the l1 and l2 run asynchronously from each other uh what you get is um that you can know synchronously that your call has been enqueued for the other chain um but it does run asynchronously which means you know it will run um but you don't get to see the result within your own transaction and this is true in both directions um a contract on either chain can make a general call to any contract on the other chain by this mechanism and then there's other functionalities built on top of that such as token bridging is uh that generally true of all cross isn't that generally true of all cross domain communication that everything will run asynchronously pretty much i think i think when you're talking about a roll-up type of approach asynchrony is seems to be necessary at least without um if you were to if you were to lock step things together more it would have side effects that you wouldn't want okay and uh john i think you're up next uh celestia what is the concept of a domain and how do you communicate between them thanks uh so for those unfamiliar i'm gonna do like a five second spiel of what celestia is doing because otherwise my answer will make no sense uh essentially it's the first and currently only general purpose data availability chain uh it's a chain that's specifically built just for data availability throughput it doesn't execute any transactions uh and before downcrowd crucifies me for saying general purpose we can also call it overhead minimized and because it doesn't execute any transactions it doesn't actually have any notion of bridges with anything else uh enforced inside uh its vm because it has no vm essentially uh so what this means is uh you can build applications on top of celestia that leverage it for shared security and those applications can define their own mechanisms for crush domain communication and celestia does not enforce anything uh so to give an analogy it will be like asking ethereum how does ethereum how how does an ethereum what how does it handle across a roll-up communication well it doesn't because it's a credibly neutral layer that you can build applications on top of similarly celestia doesn't enforce anything around cross application communication however it does provide certain interesting things when you're dealing with a cross-domain communication namely it allows uh shared security and what that means it's a shared timestamping server uh so imagine if you had like a btc relay or some sort of bitcoin relay where you still have to do fraud proofs or you know block header validity or transaction validity and stuff but you just straight up didn't have to deal with bitcoin re-arcs right you just completely remove re-orgs out of the equation uh and both chains can proceed in lock step uh that if you try to re-org one chain you would also as a consequence we are with the other chain that kind of stuff can really help cross-domain communication and it allows general purpose chains to leverage the same nice token and smart contract called bridges that systems like stark starkware and optimism and that arbitrarium have been doing you can leverage those kinds of mechanisms between more general purpose chains so long as you have the shared timestamping server so in a lot of ways it's similar to a framework for rollups and for communicating between roll-ups you can say that yes okay and uh zucky let's finish off this round of questions with you so um ibc which is cosmos's flagship you know blockchain communication protocol is an asynchronous packet-based system between blockchains that have a sort of fast finality between them and primarily exists between tendermint ecosystem blockchains uh let's see what are the other sort of one of the i think like right now i think like one of the coolest things about ibc is its general tolerance for failures of any sort of intermediaries um so like the chain that you're communicating may have lost liveness um the chain you're uh uh you're communicating uh there may now not be a a a live relayer between them um and we have like reasonable failure recovery paths between all of these things which i think is relatively cool and unique um and is running in production right now and people are sending like tens of thousands of ibc packets every day which is kind of cool very cool um so this is more of an open question for the group uh are there any specific apps that we're seeing use cross-domain communication i think a lot of us have talked about token bridges is how do we get assets from one domain to another are there any other applications that we think are going to use this and anyone can just jump in here yeah i'll jump in um so in addition to token bridges um a common design pattern that we're seeing is um applications that want to exist on multiple chains say on l1 and on arbitron using one of two patterns either they're uh sort of homed on one of the chains and open up a sort of branch office contract on the other one where um the home is the is the ultimate source of truth but um they allow people on the other chain to have whatever functionality their application provides and we're also seeing some that are genuinely dual-homed where you have a contract on each chain and those communicate with each other through a combination of out-of-band mediated communication and also the on-chain supported cross-chain functionalities and they're jointly providing functionality so we're seeing people especially in the d5 space building a lot of interesting things um in this design pattern do you have an example of the second pattern so an example of this so i don't want to name specific names um but we are seeing people who have token-based systems for example that can do minting and minting minting and redemption type of activities on both chains um so it's not the case that you have to transfer your tokens to either particular chain in order to do those things whether you can only mint on one um so that's a simple example interesting i can offer another example with respect to or a class of uh things that can could come either from uh l1 from or from other l2s um going towards starknet so i think you know the main advantage of something like startnet is that you can really compress both computation and the non-deterministic witnesses that are needed in in other things both l1 and other l2s so you could sort of have a situation where you want uh basically to relay or ask uh you know from l1 or from some other l to um starting it to run this computation let's say you know a vdf or an auction or something that has a you know compute something you know an average based on many many oracle price feeds and things like that and if you would have done it either optimistically or on l1 you would have paid either for the computation or for the computation and the transmission depending if it's on l1 or some rollup that needs to put all the data and so i could see those kinds of bridges as well and so these are non-token bridges these are basically bridges where or the communication where you want to rely on the ability to compress computation and call data on on something like start net so i mean they don't exist right now but uh they exist implicitly like you know dydx relies on multiple um computations of price oracles and all of the signature signatures are abstracted away but uh but i could see use cases where you know there's demand from it from l1 uh so kind of the general thing there is that you're using the cross-domain communication to communicate about the validity of some computation right right and and non-deterministic witnesses that maybe you want to verify on change right right um things like large batches of signatures you can just uh drop from the message entirely got it yeah very interesting uh any other examples of crosstrain applications that we're seeing um one of the things that the cosmos ecosystem is most excited about is um what we call interchange accounts um which is basically taking the idea of like a smart contract account or a smart contract like wallet uh and extending it to the idea of an entire blockchain can be represented as an account on another blockchain and has all the powers of all the capabilities of like the native blockchain on the other blockchain uh system um and it's sort of it's like it's probably less abstract than the other examples that people have been giving but like i think it's like shows like the level of excitement about it shows the demand for things beyond token transfers um generally uh so the idea there is basically that this other domain uh has an account and can call contracts or perform any like normal blockchain action yes very interesting um yeah i wanted to add james like another specific example of the kind i said is just voting so you have a bunch of stakes let's say it's an erc or governance token you want to collect votes if you do it on l1 it's going to be very expensive you could ask you know start net to do that for you so you could take something like snap snapshot and turn it into uh uh stark based you know proof that the vote occurred yeah okay very cool um so we've identified a few cross chain applications things like attesting to validity allowing a blockchain to control accounts an account in another blockchain uh uh defy apps that are honed on multiple chains and can perform all of their functions there are there uh specific ways that mev in this application differs from mev within a single domain i'm willing to go first and say something obvious which is that um you know even like in the real thing the conventional financial world apparently a lot of the arbitrage and high frequency trading is connected to you know having different systems or exchanges or markets where things are happening sort of connecting the dots and acting on them i think mev has this aspect to it which is that you even can manipulate or do things um so the more places that you have where things could sort of be manipulated then of course it just raises the possibilities but this is just a general state so like if you could influence you know both the sequencing at one place or the transactions or the mempool in one l2 and then in another side chain then of course you could have even more uh arbitrage opportunities but uh this is i think again i think you know we'll see it in the future probably this kind of ties into what ed said earlier about uh computations running asynchronously in all these environments sure and yeah let me jump in i think ellie talked you know was talking about the sort of combinatorial explosion of different mev strategies and levers that happen when you have more than say two chains or domains um but even so in the case of two i think um like the l2s i think the the rollups probably are similar to what we see which is there is a mechanism which determines the order of transactions or inc or incoming inputs to uh to our roll-up chain and that really is the mechanism that um that establishes order and where um the mev and fairness questions are going to going to be uh dealt with um so and that's because if it's an l1 to l2 call then you have an l1 contract that wants to put an event into the inbox of the l2 contract and that's essentially goes through that ordering mechanism and if it's something that happens at l2 well l2 transactions are ultimately triggered by inputs that come in and also go through that ordering mechanism so there's that single ordering mechanism i think that would be true of other rollups as well and so the question is how do you handle that um because that's what determines ordering in mev and fairness consideration so you know we've devoted a lot of attention to how we do that in a way that reduces the amount of value that gets extracted from users and that is as fair and transparent as we can make it as we evolve over time so the problem here if i can restate is that messages between domains and messages to a specific domain can be interleaved yeah arbitrum has a shared ordering mechanism for these but other like cross-domain systems might not yeah um so given the example of like uh ibc there is probably no global ordering of ibc messages between domains right sucky no there could not be and for optimism for example there could be does optimism maintain a separate mempool uh that is ordered separately from incoming l1 messages yeah we do it's an interesting question a great discussion i think one of the interesting i will call out one difference between cross-domain messages and other um just like you know within the transactions within the l2 um ed's definitely right that we that like at the end of the day the l2's ordering is determined by some like mechanism which is on l2 one interesting thing though is that that mechanism is also required to follow the l1 ordering so one one interesting thing that we see is that um if you have a transaction which is just a piece of data that is like an l2 transaction it's like a user transaction with a signature then you can attempt to order that uh like optimistically before it goes on chain and know the outcome but this is not the case for the finality of deposits because if a smart contract calls into the chain that is dependent on the l1 spinality so if you have an l1 reorg you might observe that a different message ends up coming into the chain because let's say the l1 reorg moved some money away and now the deposit can't actually be deposited so i think this is worth calling out that cross domain messages are going to be more restricted in how quickly we can get them in and choose an ordering for them because their their uh what they are doing is required to depend on the l1 state can i like respond to that briefly um i think there's actually different ways of handling that use case question is do you need to um uh evaluate the correctness of this thing at l1 before you can establish it in order you need to determine whether it will succeed at l1 before you assign it a spot in the order or do you assign it a spot in the order and then that the the result of it is um may be dependent on l1 reorgs um and there are some design choices there um which do affect what outcome you get uh so do you think we're likely to see well let me rephrase that i think that we're seeing a wide spectrum of uh choices here from a you know more tight ordering to something like celestia where there is no uh guarantee that any specific message will succeed or do anything is that right john not uh so for people i guess not familiar but uh solutions like arbitrarily for instance use uh correct me if i'm wrong ad but they use this inbox style system where anyone can submit a transaction for the rollup and they can submit it into an inbox contract on the l1 is that correct uh yeah that's part of the story um we also have a sequencer which has limited power to reorder transactions in order to make faster guarantees yeah so you have those those two components so i think what james is alluding to is he's saying that celestia would only have that first scheme of uh anyone can submit a transaction and then it come in any order for the l2 but that's not exactly correct because you can also do batches of transactions and in fact you can have entire blocks on top of celestia the application can be blockchain based and they can have blocks and you can decide your own sequencer aggregator or however you call it and for example they can be the only ones that have the right to produce blocks with application and everyone else you just ignore the messages that they post so you can get essentially the same same thing that you get out of rollups on top of celestia you don't have to worry about this kind of anyone can just post anything at any time but i did want to mention one thing uh relevant to your question if that's okay uh which is that i'd like to invoke the what i call the law of conservation of mev when it comes to layers which is basically that you know mev can't be created or destroyed well it can be created it can't be destroyed it can only be moved from one layer to another uh which is a completely not not scientific law or anything it's just it's just an observation which is basically saying that if you have a roll up you're not going to have less meb you're just going to move the mev from the best you can do is move the mev from the main chain to the roll-up which isn't inherently bad especially if you use only batch submission style systems and no inbox then the layer one doesn't see the mev it just doesn't see it because the only people who can submit blocks are these layer two sequencers that comes with a zone set of trade-offs uh but you can move the meb to a layer two but you can't eliminate it it'll still be there in terms of quantity uh so the mav of the total cross domain system is always increasing at the very least yes it never decreases i don't know that that's true in general actually um you have their degrees of freedom and design that you have in an l2 system that don't exist in the fixed architecture that exists sort of on ethereum l1 and so you do have opportunities for design that ethereum doesn't have because ethereum you know already exists and has baked in a certain approach um so i don't think it's at all a theorem that you can't reduce med um it's not easy and if you just careless about it you probably will maintain or maybe even increase the extractable value but you can do better you're willing to innovate in design so i should clarify that when i'm talking uh sorry very very quickly if you don't mind i should clarify that the with the observation i'm saying is mostly about if your layer two functions the most naive way and exactly the same as the layer one then you're not removing mav of course you just like how you could change layer one to reduce mev you could also apply those changes and experiment with new techniques uh for sequencing aggregation mbv reduction on the layer too but that's orthogonal to the fact that it's all there too like you could do those same things on ethereum if it wasn't for the fact that needed to maintain backwards compatibility uh okay so this kind of segues nicely into the last thing that i wanted to talk about before we wrap up the panel um which is uh whose job is it to reduce mev should it be the job of the system developer or the job of the application developer and when we get into these cross-domain systems uh who has to do all of the work to minimize mev and communication between them and i want to because we're wrapping up i'd love to do this last one kind of round robin give everyone a chance to speak again and uh let's start with ben cool i mean it's a great question james and it's the philosophical one that i think will get thrown out on every single meb you know flashbacks talk from now to the end of time i think the responsibility is on both parties and i think that there's a trade-off between doing it in within the system in terms of how universal you think those fairness properties are so i think the tricky thing is that we don't yet have a result that says uh that any particular system can have general applications that are mev resistant in some in some way by nature of the system like it's not obvious at all that it's for any system that is not you know trivial that like actually can have economic activity that there's not some application that you can put on that system that introduces mev so fundamentally that seems to put a lot of attention on to the application developer if we don't know yet if it's even possible for a generalized med resistant application there are obviously things that we can do that are very useful heuristics and that feel very fair it may be different between who thinks what um but fundamentally some of it has to go on the application i think because of the nature of that you know systemic unknown interesting um ed do you want to go next i would agree with ben that um it has to be everyone's job because it's a hard problem and you're and they're hard trade-offs right so system design should be uh trying to reduce or mitigate mev as much as possible but then there'll be some part of the job that will fall onto applications but it's also important for the system designers to create affordances that are useful to application designers so that they can fight the particular mev or front-running issues that afflict their applications um so it's not just sort of fighting it separately in each layer it's also about what can the base layer do to to help the application developer have the tools they need ellie so i i take my inspiration from what happens in the conventional markets there um you know you're under the assumption that if there is a flaw someone will use it and try to um you know front runner or do whatever wash trading or things that are illegal and then it's the sort of the at the system level you ban it by by law and regulation the analogy to that is that i think it is of course you know it's objectionable to uh from from do things like that and you know uh operators and whatnot shouldn't be doing it but i i think you would like in a decentralized you know protocol based system you would like to put maximal effort in getting a protocol to eliminate reduce you know to the maximal extent the ability to extract value from from these things and then you know and because especially in this anonymized permissionless world it's going to be very hard to uh assume that that uh you know that developers are going to be moral uh you know it's not the case so you really need the protocol to solve it um john sure uh i would say i'm mirroring what ed said that the protocol development developers under the assumption here that the protocol is some sort of credibly neutral public good probably have responsibility to at least build tools so that application developers can minimize the mev that the applications they build have i think it should provide appropriate tools for this uh and so it is at least partially the responsibility of the protocol developers i'm not really sure if the application developers have any responsibility i guess it depends if you're talking about if it's like an ethical responsibility or a financial one uh then it depends if the application is a public good or if it's just some financial application pro application developers and i think the ethereum protocol developers had to learn this the hard way with things like refunds the application developers have one responsibility assuming the application is not a public good the application developers have one responsibility and that's to make money for themselves and to a certain extent for the users in as much as that makes themselves money uh and in that regard maybe doesn't matter as long as you can make money and that's why you see things like gas token happen so if the application is a public good yeah they should probably strive to reduce mav if it's not we shouldn't trust that we shouldn't uh we shouldn't assume that they have any such responsibility in my opinion interesting and let's wrap up with zucky so two things what we found is practically um attempting to reduce mev propagates dependencies like up and down the stack um so like the demand to uh reduce mev is like changing apis within how tendermint interfaces with the application which is this idea called abci plus plus um that is sort of propagating like mev related ideas all the way down into like how tendermint works um and on the other hand like yes mev is very application dependent and very much the idea of cosmos is that people could co-evolve like all layers of the stack to provide uh the optimal user experience um you know and to go to like a little bit like why do why would someone want to do this why do people care uh people care because uh uh mev live reduces like takes value away from their users and send it to other parties and uh you might will probably be more successful in acquiring users if that doesn't all right uh thanks for your time everyone always a pleasure to see each of you i think sunny is up next