Interoperability between L2s: Latest developments, Framework and Challenges | Devcon SEA

[Music] awesome uh so I have a lot of information to get through um so I'm just going to get right into it this is specifically about trustless interoperability between l2s bit of a wordy title so I just decided to keep it here but basically the motivation for this talk today is when I joined the space somewhat recently um I decided to kind of look at the interoperability problem immediately and right upon doing so you can see everybody kind of has different definitions for how they talk about these things we see Atomic inclusion Atomic composability synchronous Atomic composability um asynchronous composability these are very confusing things so my aim today is to sort of clear this up and figure out what we actually need to make these things happen so I came up with with what I call the six level framework for discussing inter oper trustly um this is a broad overview uh in the interest of time I'm going to move Beyond this but I'll give you a second to take some photos and uh and just get an understanding of what is sort of the impact of each of these levels so uh getting right into it this is the default case this is what we have right now if you want to move between rollups you can't really interrupt you have to withdraw you have to wait once your funds are out then you can deposit in the next destination rollup that you want to go to but this sucks Atomic conclusion um this is where things start to get a little bit more interesting I think the way to understand this is we have a bundle of transactions and we have some sh shed shared sequencer that can guarantee inclusion but it can't tell us whether things are going to execute successfully or not so we can see over in the bottom here rooll at B might revert one of the transactions so the impact of this is that it's actually really difficult to take advantage of any sort of system with just Atomic inclusion guarantees because if you want to create a bundle of dependent transactions uh you can't because if one revers then this is going to have issues on the whole system so uh the necessary infrastructure would be somewhat of a lazy shared sequencer and we can go into the technical nuances after if you have questions so um I'll just keep moving on the third layer is where things definitely get a lot more interesting this is shared settlement and this is what we're going to see a lot of in the next year so things like the a layer for polygon ZK syncs elas chain super chain they are all doing this and the definition is having multiple rollups all settle to the same shared Bridge contract uh there's usually a proof aggregation step involved in the middle as well um but that's technically not necessary and we'll get into why uh maybe afterward and so the advantages and capabilities of having shared settlement is that you don't have to wrap assets to go across chain because we're sharing the same Bridge contract uh we don't have to worry about managing the account accounting on all these different Bridge contracts on the L1 so that's great we can go native eth to eth and that's all in the Protocol no bridging required um so we need a share Bridge contract we optionally need relays again not going to get into the Nuance of that um and we need proof aggregation to do this as well so next we have Atomic execution uh and the idea here is the exact same as atomic inclusion but now we can guarantee that these transactions will execute when I say execute that means they're going to create the required State change that they were intended to create on the chain that they were intended to go to uh and this is really really important because now for things like cross rollup Arbitrage we have guarantees if you don't have guarantees you might get involved in a case where one of your Arbitrage transactions goes through the other does not you don't actually profit uh people do this right now this is kind of what sexex ARB is for the most part I mean if you don't get top of block space but it's suboptimal so we you know we want to have something like this that guarantees that transaction bundle to go through and now we start to need more shared components in the middle we need a shared sequencer we need a superb Builder technically talk to me after um and a soft finality later technically talk to me after um this is where I want to spend a little bit more time so this is what I think should be the goal for now at least and this is Block Level composability this is a really crazy diagram and I'm not going to go through every single step of it right now uh but basically the idea here is that we can compose between rollups within a single block so a lot of times on Twitter you'll see people talking about oh we need synchronous composability what does that mean mean uh this is one way that they mean that where you can have this dependent cross rollup bundle of transactions uh and this is really important because now you can do things like single block cross rollup swaps and limit orders trustless Le and the trustless component means that you don't need a liquidity Bridge you don't need to trust any sketchy intermediaries you can do this all with minting and burning in a in a safe way uh you do need a shared sequencer uh or a superb Builder again I keep we'll talk after if you're curious about why I keep going or super Builder it's actually pretty nuanced and really interesting um and then the soft confirmation layer again not strictly necessary but this ensures the validity of the bundle so you can think about creating this cross rollup bundle of dependent transactions as uh a somewhat risky thing to do but if you have this soft confirmation layer that ensures hey all these transactions were well uh well formed and we've simulated them uh we can give a pre-confirmation on that bundle so we can ensure that we can do what we want to do this is the final step and this is technically the Holy Grail of cross rollup interaction this is basically a smart contract to Smart contract layer uh of interop for these rollups now uh the really interesting thing about this case is that it basically ensures that any state change prior to any call can be reverted if the call reverts so this is what we want in smart contracts right now you make a call out to another smart contract the call reverts for whatever reason any State change that happened prior to that call must also be reverted and that's really really important for the developer experience because you can't take advantage of any cross rollup opportunities if you don't have that because you don't want to act on state that did not occur in the domain that you wanted it to occur in so this would be like the Holy Grail best case version this is amazing but it's really difficult to get um and yeah so the advantages and capabilities smart contract like experience across all Roll-Ups this is amazing we can guarantee that any state change can be reverted cross rollup Flash are possible we need VM level changes we need a shared sequencer we need Super Builder we kind of need as much shared State as possible without literally being on the same rollup so what's the takeaway Block Level compos composability is the right goal we should not be optimizing for cross-chain Flash load um we need shared state to compose so we need a shared sequencer we need a shared super Builder some sort of shared state to go back and forth here um and the last Point I've got seven seconds left uh rollup clusters you're going to hear a lot of people talk sadly about these because they're walled Gardens they're fantastic they're really good for the middle ground and we're going to work up to a place where we can bridge between all of them so thank you thank you Marshall that's it we are not taking questions uh if you