The Chain Abstraction Master Plan by Stephane Gosselin | Devcon SEA

[Music] wow I remember uh the first Devcon in 2017 it was not like this uh production value is so good now um hey everyone uh super excited to be here my talk is titled the chain abstraction master plan um so I'll talk about a few Concepts that uh that we started a company to explore um and try to go into what we think we can achieve by uh by using these things um so let's dive right into it um to set the context I want to go back into sort of the what I would consider the main phases of ethereum and the challenges that we' sort of had to explore and face along the way um initially when when ethereum came out the idea was that it would be the world computer you would have a synchronous environment there would be one blockchain and you would put everything on it um and so I would I would DM this to be the big ethereum uh stage of of ethereum then something happened in 2020 which is the Chen ended up being unusable uh because gas prices spiked to an insane level um I think this was sort of the the start of of defi summer and yield farming and all this fun stuff um and so the new idea came out which was let's actually put everything on a handful of Roll-Ups um and I would call this the the big rollup phase of of ethereum um and then more recently uh We've sort of seen that the rollups themselves started to uh split up into their own thing um and so now the idea is you have uh sort of an app that's on its own rollup and so you have clusters of uh of rollups now my claim is that this is is sort of fundamentally broken for all the reasons that uh that people experience with fragmentation um and there's a particular Solution that's needed to be able to enact it um and that solution is called resource locks so resource locks is really the thing that one balance was founded to uh to explore uh and propagate and our goal is to really uh bring this as a fundamental component to the entire uh ethereum stack um so let's go into resource locks let's talk about intents and let's talk about how it helps achieve Atomic interop um this is a a graphic of the resource lock stack we published an article called the cake framework that explores some of this um and uh the resource locks is just this piece in the middle here so it's one of the many uh messages and interfaces that need to be introduced to be able to achieve a fully chain abstracted uh sort of uh endgame for uh for ethereum um and it only works when you have some of these other components that are being added to to the system the thing to notice here is that this is an intent-based architecture right so it uses solvers to be able to execute transaction on chain on behalf of users um and then proving the execution back to wherever the the execution uh originated from now the magic behind resource locks is really what allows us to achieve this seamless interoperability in uh in ethereum so let's go into talking about what a resource law is it's really composed of two things um and there's many shapes and sizes of resource locks um so it's finality protection and equivocation protection and this is actually one of core properties that blockchains offer just the problem is that blockchains offer it in a very very expensive way so if you sort of abstract away the concept of these two things and then you add them up with the concept of an intent which is specifying input State and output State um you can achieve something that we refer to as resource lock and contents um and so this is what we sort of believe is a fundamental messaging uh format for anything that will be cross-chain if we want all of uh ethereum and all chains to operate as a unified uh component we can explore how uh intense and resource intense uh compareed to some of the other interop uh approaches and their and their trade-off so canonical bridge this is how do you pass a message between two l2s in the most secure way possible you have to start the message on the uh first L2 send it through uh the fraud proof mechanism wait seven days and then pass it up through the canonical bridge on the other L2 uh for messaging and the core thing you have to wait for here is full finality over the message passing which is why it takes up to seven days for for optimistic rollups how can we go faster well one way that we can go faster is just be optimistic about the finality so when you deposit crypto inside of a custodial exchange you don't wait for the full finality often times you wait for some optimistic version of finality so for an L2 deposit usually you'll just wait for a single rollup blob to be posted to the chain and the exchange FL considers that to be final final enough to be secure uh but you still have to wait for this sort of full rollup blob to be uh put in so how do we go faster well intent Bridges have become much more popular which is an approach to actually um uh send the message through a solver have the execution happen uh on chain um and then uh uh uh prove that back to the origin chain that it was successfully included the problem here is that you're still relying on the source chain for providing the resource lock which means that you still have to have uh inclusion times on the origin chain before the solver can do the inclusion on the destination chain so you're still fundamentally two inclusion times away from uh from uh from Atomic execution and and then resource locks take away that requirement for execution on the source chain and says actually all you need is a signature from the user and you can automatically in instantaneously go and execute on the destination chain um so this is sort of fundamentally the fastest way that you could do interop because you're always operating at a destination chain speed so um This falls under a category of interop that that we call sort of atomic interop or Atomic execution interop um as opposed to Atomic inclusion or Atomic composability and I want to compare it with some of the other approaches that are being discussed for uh for Atomic interrup so if you look at sort of in cluster interop between the ZK rollup land and the optimistic rollup land you'll see some of this terminology come up um so agay and elastic are are both ZK rollup clusters um and they uh they are limited by some fundamental constraints so one is the proving speed of the rollup itself so you cannot send a mess message within this inop uh system faster than the proving speed of uh of a of a ZK um a zare proof um and if you were to assume that you had uh real-time proofs which is sort of like a standard that we're that we're looking for even that uh in that world you're constrained by the fact that you can have cascading reorgs across two different rollups so if for whatever reason the L1 that you're posting your your blobs to or your proofs to ends up reor working away that uh that blob and you end up posting a different uh set of transaction any other rollup within this interop ecosystem that's listening to that post will have to also reorg and so you sort of have these um these security assumptions that are conditional on other uh other uh security environments so it's not ideal um super chain and ARB clusters have very similar sort of guarantee requirements so it requires a superb Builder which is just a a sequence that's going to be sequencing uh both the any of the rollups are being touched by uh by the multi-chain message and the implication of that is that you're completely forgoing uh chain sovereignty um which means that every single rollup within this optimistic uh interop cluster need to behave according to the exact same rules and need to upgrade uh following the same assumptions and so if you have you know within the super chain environment uh the unit chain and the base chain any upgrade to the sequencer or behaviors would have to be coordinated and have to be mutually trusted because the risk is that if the unit chain has a fault for whatever reason and produces an invalid message it could cause also a reorg on the base chain and so these cascading reorgs make it very very difficult to achieve this um in a in a scalable way um what about resource lock intents do these have any trade-offs well yes they also have trade-offs while they don't uh they're not susceptible to some of these uh reorg issues because of the resorce loog nature of it they are constrained by the liquidity that's available through uh through solvers and they also are susceptible to Black Swan risk for example if uh all the liquidity ends up moving in One Direction at the same time you know the the liquidity providers could shut down and you would be unable to actually um execute the the transaction that you're looking for so where does sort of one balance fit in um well I hope I made a case for why resource lock is like a useful primitive for Atomic uh interop on uh between l2s um and our approach is really to provide a toolkit for any apps and wallets who want to benefit from this instant cross chain execution to be able to do so um this Pro this provides basically the full chain abstraction uh experience for these wallets right a completely chain-free Bridge free and gas-free uh user experience and we have an app that you can go and try out that has uh cross Shain swaps um and uh and experience what this feels like um the other uh product that we have is what we call resource locks as a service so this is a product really tailored towards uh infrastructure providers and it provides these guarantees of reorg and equivocation protection it really allows for a completely trust minimize uh destination chain speed execution um we also implemented just before Devcon what we call teleport so this is a token wrapper for eth that allows you to instantaneously uh send eth to any other uh chain or rollup without having to wait for inclusion time um and so yeah it's a it's a really cool uh way to be able to transact on any chain at the speed of uh of that destination chain um I have this slide uh as a bit of a troll to uh a slide that we saw earlier this uh this week uh which is you know I think it's important for us to be ambitious about solving the problems that ethereum has uh sooner rather than later and Achieve sort of the ux gains that uh that we want uh given the the environment that we're in and so what's the timeline for this well it's already live right like this chain abstraction stuff is is uh is sort of built out Tech and it's ready for anyone that wants to experiment with it and uh build it into their applications in prod uh for them to do so um and so yeah they encourage uh everyone that's thinking about uh operating and building apps or wallets to uh to look into resource locks and and understand what are really the benefits that uh that they bring so that's it thank you so much for uh forist listening to me okay we have three questions um so first question is why does everything need to be fast as can we leverage the better Channel capacity usage by load balancing uh you know fast as is uh the optimal goal right you could say that like what is the actual time that you're looking for from like a ux perspective um I think like a two-c goal of like being able to ex execute is is pretty good now you can say okay can you uh achieve that through like regular other channels uh that I've described in in the in the in the framework um maybe but you're still susceptible to all of those trade-offs that I explained um and so even if you have like seemingly uh faster uh uh channel uh uh messaging you still have a bunch of trade-offs included which why I think resource locks on top of it will always be used okay next question is uh do relays need to have liquidity on every chain and rebalance accordly and is this a problem uh yes and no so instead of relayer I like to use the uh solver terminology um and you can have solvers that have inventory which you know you would refer to as market makers or solvers that don't have any inventory and the ones that don't have any inventory if essentially pull the liquidity from liquidity pools on uh destination chains the other thing that you can is you can have native bridged assets so realistically the majority of the volume when you go in a cross chain setting is going to be eth or some stable coin stable coins benefit from being natively minable on any of the chains and so you don't actually need to hold inventory on that token in those chains you can instantly mint it there and there's also work being done on the eth side to be able to make canonical minting of eth on any rollup um and that will also prevent the need from having uh um invent on those rollup for solvers okay uh what are the security guarantees of source chain signature validation by the Rel layers on the destination versus systems like 7683 and why should we trust this more signature validation by the relays on the destination versus system okay that I don't get the middle part of this question but I can I can say like okay what's the difference in the resource locks between an intent bridge and a resource Lock Bridge um so 7683 is like this intent standard uh and it provides some of the uh the fields that you would have when you're trying to do uh uh resource lock resolution on chain um I think it doesn't specify anything about the uh commitments that are being made about the state of the account when you're inputting it it just so happens that right now we're doing this by putting it on the source chain um but there's a bunch of mechanisms that you can do to secure resource locks that are fully off train I won't get them in this presentation but I would just point you to uh to our eth research post about resource locks okay since the time's up um that's it there are more questions and you can find him here um thank you thank you