DAPPCON 2024: How To Achieve Ethereum Layer 2 Interoperability - Hilmar Orth

Transcript

hi everyone great to be back at Devcon I think I've been here most years since uh my first presentation in 2019 so always always glad to be back uh audience is growing I like to see that last year in the bare Market it was still uh fewer people um yeah today I will be talking about um ethereum layer 2 interoperability um and specifically not just interoperability for the sake of interoperability but actually uh we believe it enables a whole new sort of class of smart contracts to be built which we call infinite horizontally scalable uh with free applications or smart contracts and I will be diving

into what that means in a moment and uh it's actually quite timely um vitalic the man himself tweeted today about um layer 2 interoperability um emphasizing uh how necessary it is and sort of also uh talking and promoting a bit that we need like standardized systems and we shouldn't build too much sort of isolated system uh in the industry and so I was just want to PL plug that in because I think it was quite timely uh was like 10 hours ago and if I want to if I want you to get anything out of this talk then it is sort of this concept which I would sort of classify as a pretty bold Claim about the future

of how you build W applications it might not actually end up like this but I think there's a strong likelihood that this happens and um the first one is that apps actually won't build on any shared blockchains anymore and this you might have heard from like the application specific blockchain hypothesis right it's it's fairly similar but um I want to take it a bit further and actually say applications won't build on a single blockchain you will have applications that build on more multiple horizontally scalable in in and interoperable interoperable virtual machines and these virtual machines I.E these layer twos um they will scale elastically so they can be created and they can be destroyed and

with that you can actually horizontally scale applications to the world like we do in web 2 and this requires a pretty big shift in how we think about smart contracts and designing them we need to think of smart contracts as modular systems and not sort of Monolithic systems that are based the way the state is based on a single chain that's me I'm hmer one of the founders of gelato um if you don't know what gelato is uh we building web fre Cloud platform um and we try to enable developers to build verifiable horizontally scalable blockchains and applications with a bunch of really powerful web3 Services um so at the core it's a ro bus service platform where we host layer TOS all the optimistic rollups e rollups that you know we try to make them as inter

interoperable as possible possible for you you can have multiple layer tools that you spin up concurrently um uh we want provide you with shared sequencing uh on top of that so you can um have higher guarantees at Atomic compossibility between them and on top of that we have a bunch of really valuable web free services that enrich these applications with offchain data verifiable Randomness you can abstract complexities like gas as well so we provide you with all of that on a single platform and we've got a bunch of really awesome chains that already live with us from AA the first polygon cdk connect to the ACT layer to list from the op super chain to rea the biggest per application L application specific per decks on L2 um that actually went trading went life

with them today which is super exciting and many many super exciting ones on the pipeline so stay tuned um but yeah let's Jump Right In into like the more technical part which is this is sort of how the layer 2 landscape looks like today so you have a bunch of isolated layer twos where each layer two this is of changing sling law mostly has their own individual L1 to L2 canonical Bridge um this is of course not optimal because uh you might want to uh aggregate assets into singular sort of um Bridge contracts so you don't need to move them on L1 if you need to rebalance if you want to move assets that are originating from L1 a between l2s um then uh you

have monolithic layer twos that are not Comm communicating with each other or they are communicating but with third party valid data cross messaging protocols in a very sort of high latency environment um and then you have sequencers or you can think of sequencers as block builders that are building the blocks so um ordering the transactions of each of these l2s in a way which is super isolated and so one sequencer doesn't know what the other sequencer sees on his chain or or another one um so it's very isolated everything and if you're building an app you sort of say okay I either want to build my app on l21 or on l22 or I want to build my app on l21 and two and three uh but they never communicate to each

other so you just replicate them uh so yeah it all doesn't really make sense that much um and on top of that these chains are already struggling to scale right um chain scale uh via cheap sort of computation and data availability that they can access this is already this has some pretty good progress uh with like 444 and Celestia and all the other the coming up but the uh the execution the execution environment the VMS are actually getting the botton acas with bass really like hitting it off sometime a March and it spiked tremendously um and so vm's already becoming the bottleneck for these chains and if we really want to do Mass adopted if you want to build

applications that have millions of users then our current VMS are just not enough uh you can build parallel VMS but at some point they also sort of uh end in terms of the performance increase right um and if you're Building on Base let's say you are just building an application but suddenly there's this Deen uh nft uh that consumes all the gas obviously you're out of luck and your user experience suffers a lot um and you can't just migrate to another chain right you're kind like stuck this data is stuck on that chain and so yeah you can't really do anything and so um how we can solve this um from like a technological point of view from an architectural point of view is by having more shared systems between the different l2s and having

standardized systems so firstly uh what would be great is having like a shared layer 2 bridge where everyone can deposit their assets into on the L1 and then each L2 can sort of derive what assets it has based on the uh the assets that were locked into the bridge and some sort of pointers that are in there and the cool thing is if you want to actually move assets from one chain to another they don't have to be moved on ethereum by transfers they just sort of you update it with a mer root the different balances um then um we need communication trustless ethereum grade communication between uh the l2s Via a shared inability protocol which I will sort of discuss in a moment how this can be designed from like an optimistic

roller point of view um and then shed sequencing what it enables it if you combine it with interoperability it brings you um Atomic composability so you can say rather than crafting a block for for layer two number one you can say I craft a block a super block for layer two number one and layer two number two and the block is only valid if transaction a was included here then B here and then C there and then D here again right and so you can sort of atomically execute transactions between them and the cool thing about this and this is sort of what I want to bring home at the end of the day is you can build applications that sort of change State and move from one chain to another and sort of evolve a dynamic

with new chains being span up so I'm talk I will talk a bit about the optimistic Ro of design and how we can achieve it here um a lot of research has been put into this especially for like the op Foundation arim orbit is also working on this polygon is working a lot on the ZK side and I know I was I'm really bullish shortterm around the optimistic rollup side vitalic posted today that hey in 10 years it doesn't really matter everything will be ZK but I think the emphasis uh here is in 10 years right so I think there will still be a pretty sort of long period now where we will first dive into optimistic rollups and everything and so some definitions first what do we want to achieve here with the Central operability and we want users to be able to submit transactions on chain a and we

want this sort of information to be transmitted to another chain so this chain B should be able to read from chain a there also other things you can do is like chain a writes the chain B but this is a bit more complex out of the scope and then there's initiate there's an initiating message on chain a that the user sends and then there's an executing message on chain B that like the user can send as well or relayer or anyone really a block Builder can include it and then chains can control which other chains they actually will allow to communicate with so if you have a chain you can say hey I allow chain AB BC to send executing messages to my uh chain that I have to verify and this is sort of like the high level process of

how this works so what you do is you can have let's say you have op stack rollups right um and you have let's say five of them you will predeployment pretty high trust in these chains that uh all the sequence transactions are actually sort of like conform with my what I want to achieve but maybe also have um maybe you also trust some other

chains right maybe Bas or op mayet you want to integrate with them so you widel less them and then what happens is that let's say there's a transaction on a chain um relays will sort of uh get paid or incentivized and relays could be block Builders at some point to then submit transactions which originate on other chains to the sequence of let's say our chain our home chain um and they will Point them to uh an identifier that enables the sequencer to say that a the sequencer to find that a particular event that was emitted on the foreign chain and this consists of an event index chain id address and then the sequencer will be able to validate whether this event was actually

happening on the other chain and will include it into his own chain the executing message if the event was not emitted on the foreign chain then he will discard or she will discard the the transaction um and um reor reor out so it it won't be included and the whole system is actually not secured by some ex Val that set it can be fully secured by ethereum using a multi-chain fall proof and what it means is that rather than you having to prove that um um the state r that you're publishing as a sequencer to the L1 from your own chain are correct you need to now prove that this St is published to not only your but all the other chains with the dependency set and potential the

dependency sets of those um have been done correctly so um yeah it becomes much more difficult to actually build these blocks um this is more like a diagram on how how this looks like it starts at zero here so user sensor transaction to let's call it base um then relays will listen to this and send an executing message using the data that was emitted here to my chain right this is the Hilma chain right here it listens it has base as a dependency what I now need to do as a sequencer is I need to verify whether this was actually emitted here and if this was emitted here I will include it in my batch that I post on ethereum and then once I post my batch to ethereum

anyone can go in and actually check whether this event was actually emitted here and if not can submit a fraud proof to potentially slash my stake um this as you can see makes it much more difficult to become a sequencer right because you now need don't need to be only aware of this chain but also this chain this chain so you need to be quite careful which chains you add in your dependency set um and these machines will be beefier but I will go into some trade-offs in a moment so the great thing about this design is that there's no Force inclusion meaning you don't have to sync all these thingss together um um why why does it still work because we actually rather than having like an inpr protocol rule that all the transactions that have been emitted need

to be executed we make it we Outsource it to the block Builders right we can say hey events can be emitted but only if someone really incentivizes you to relay that transaction on the destination chain will block Builders actually come in uh and do this and this is cool because we don't have to like in ethereum with like withdrawals we don't have to implement some Q system and we don't don't all have to sync all the chains together we can all have them run asynchronously independently and let the block Builders really handle the scalability of this um if you combine this with Shar sequencing um you can actually get Atomic composability if the block Builders have sort of monopolistic power over building blocks between one chain or another and then you can have

transaction a the originates here relay to B then back to a then and back to B here and then you can have some sort of flashl potentially even um and yeah this all works with like a multi-chain fraud proof so um there's no additional trust assumption in the system some cons some cons of this um uh it leads to centralization so basically winter mute will build all the blocks uh right but they kind of already do um or and it only works for certain optimistic Frameworks like your P deck it can also work for like the orbit stack or other Stacks but it is very difficult to make cross framework right now and of course it would be great to if we can all do a cross framework but this uh unfortunately is a bit harder but

there's also some solutions to like the centralization of building like uh veral trees and stuff like this it just makes it much easier to verify the state of other chains right but this is all a couple of years out unfortunately so now an example that I I like to use to sort of now this was the inability part right but what about these new smart contracts they just like scale right how how how are these actually being built and so let's imagine we have a perex and let's imagine this perex actually consists of two chains one chain has all the assets in the world that are traded against USD and then one chain has only eth versus USD that you can trade there right and all the because e us is the highest

volume pair with the most traits it needs like its own chain to really sort of uh satisfy the demand of the users um and now what happens is that paper uh a mcoin you might know starts really going crazy right and a lot of people want to buy and sell paper right and the virtual machine of the longtail USD L2 really gets to capacity what we can do is we can dynamically spin up a new equal virtual machine being like a layer two and we can migrate the state of paper USD all the assets all the orders and everything you can think of this as like an onchain order book um to

this new chain and the the users will just like sort of send transactions VI like some API probably and it gets routed always to the to the right chain assets can be moved freely between them and now we have a dedicated virtual machine which only handles paper USD right um and now the system scales again and everything works well let's say paper volumes go down again now paper no one cares about paper anymore everyone sold it and we don't actually need this dedicated instance anymore what we can do is we can again with like an offchain worker that does this that monitors like the the loads and so on um we can migrate the state away from these new l2s back to the old one to this general purpose one where we you can think of as like the Hub right um and we can spin

them down so we can deprecate these chains and now we are back to only two two chains you see it's very similar to like horizontal scaling and web two um what do we actually need to sort of like build this out and make it work we need to abstract away the complexities of managing state from developers across many l2s in sort of like this elastic Dynamic way there are some ideas around this using distributed hashtable libraries and so on but yeah it's this still has to be built right this this is the the complex part we need these offchain systems that actually like uh monitor the loads that these systems are getting and the capacity limits and then spin up new chains and sort of deprecate them again

this is we already have a lot of this ailat by having to service a lot of layer twos in production that sometimes like get 10x usage for an nft drop in a moment and we have to replicate instances and spin up new VMS and so on but this has to really happen with new chains that are then migrating States so it becomes much more complex um and this whole system has to be done in a way where it sort of works well it resets itself it heals itself right every time there's a new chain deployed and there's a new chain destructed um this probably won't work for all the applications right I'm not saying this will solve everything um but it will definitely I I see a lot of use cases like onchain order books where you can split via pairs or you can even

split between Pairs right um or you can have certain engines that only focus on deposits and only focus on sort of trading and liquidations on like different shards um but yeah it requires a lot of additional tooling and has to be built um and yeah of course it would be great if we can harmonize it between all the different sort of clusters that are being built right now I think uh italic today said um he's not really happy about having five separate solutions for five sub ecosystems that's needless um fragmentation this is kind of like what is happening today with all these ecosystems being built in parallel it would be great if we can find like a harmonizing way um probably something what like ZK proves at some point will

enable this but yeah right now uh basically we have these separate instances sort of being built and I actually believe there will be many many more in the next sort of year or so um yeah I think that's already it if I want to bring one point across is this sort of new way of building smart contracts not on one chain but uh you have 10 chains behind a single application and uh yeah we are sort of experimenting with this and so if you're interested in building I don't know the next binance on Shain that really needs infinite horizontal scale reach out to us we work together with a bunch of cool projects that are having similar sort of ideas and yeah thanks a lot for listening thank you hmar uh we have a

few minutes for questions here down in front in the blue shirt hi thank you for the talk um I actually have two questions if I have time so the first one is about the sequencer centralization you touched on it already that when you um wh list some chains in your dependency set actually you're kind of wh listing the full dependency graph right because this chains in the dependency set will have possibly different chains in their dependency set and so on um so does this mean that the sequencer actually when they have to verify the inclusion of a certain initiating message possibly they have to verify the full dependency graph yeah so which means that you know um possibly you're not really scaling in a

sense like you scale with the number of you have ch in your dependency graph yeah you have to really be mindful of who you whiteless to this right you can't whiteless chains that have I don't know 100 different dependency sets to all sorts of random chains that you don't trust um so it has to be especially in the environment where you have your chains interconnected with each other uh you can really horizontally scale forever if you want to use this to interoperable like with foreign chains let's put it right you have to be very selective otherwise yeah it grows in terms of the workload that you have to do and the uh remote chains you have to verify and this yeah leads to centralization of block building white listing is also offchain like it's nothing onchain right in the future they could wh list someone else and then

you're kind of mindful for others let's put it in this way because you could dop like how optimism actually tries to solve this they have like the governance right and uh they have this governance layer where they actually decide what to Whit less and so and so you will probably have these enclosed environments where you interoperate rather than just letting everyone go crazy yeah that makes sense yeah I have another question if nobody is another question go ahead please so this chain on demand approach that you um presented where you spin up you know another execution layer Whenever there is need for it um wouldn't it be simpler and maybe equivalent to just let's say increase the gas per block maybe with some

protocol to increase it for specific applications but without spinning up new chains without migrating the state just having a more flexible you know gas economy let's put it this way you mean vertical scaling yeah I mean in the same chain the gas per block can increase dramatically I mean this cannot happen now I'm saying would it be equivalent yeah so vertic like basically vertically scaling single instances right in yeah so there are two approaches to scale right vertical and horizontal um vertical has its limits eventually right you can't vertically scale forever um and so you will at at some point hit a p hit a hit a threshold there you can go beyond uh it will become also increasingly tougher to verify this particular chain for everyone else right

uh whereas like if you just want to verify this particular chain everyone can still do it if they don't if they don't need to uh verify all the other dependencies and so yeah in web 2 you also don't have a single server fat that has everything right Amazon scales vertically sorry horizontally and there probably a reason why we believe this might be the superior architecture okay but in a sense it's the same problem like you're centralizing that's the same tradeoff kind of right with today like block building and verifying everything will become uh more and more centralized it is already happening I would say yeah thank you another question uh the white shirt hi

uh thanks for the talk uh I I think you mentioned that in the example the use case but I just want to ask again see if I understood correctly how does it actually solve uh the liquidity uh problem that we have across layer ches today Yeah so basically um in this model where you have the native interoperability between multiple chains you can spin up new chains and atomically move over assets um in like I don't know a second a block or something to the new chain and then conduct all the trading there as soon as you the chain is no no longer required you can reconsolidate the state back and the state means the balances and all the assets and and ie all the all the tokens

uh with VI like mint and burn mechanisms back to the other chain and then deprecate it so it has native interoperability IE native bridging um in there and then with the shed sequencing on top you have uh composability where you can actually sort of do the mint and burn and like is uh atomically across different uh l2s yeah any other questions out there for hmar all right give it up for hmar thank you so much [Applause]