Aggregation Day Panel: Path to Synchronous Composability

[Music] wow that was really really cool I need the audio from whatever they used for that uh so next up we're going to have a panel uh called the path to uh synchronous composability uh so what I'm going to do is use my ultimate uh stage powers to start bringing people up here um some people would say I'm drunk with power I would say that oh I put bobin in there nope sorry bobin not this one uh someone say I'm drunk with power as it turns out yes I am and no regrets on my end for that all right awesome so we're going to go ahead and take the slides down thank you all for uh joining us today I'll go ahead and uh just say everyone's name uh Zaki is here uh Brendan is yet again moderating um uh Ilia is from the near Foundation uh s Ram is Igan layer and Ben is from espresso oh and I didn't even mention Zaki is uh inclusion and like 19 other projects so welcome and uh we'll just take it away from Brenden I uh I did not realize that I was moderating this one as well if I was unqualified to moderate the last one I am surely surely unqualified to moderate this one um but it's really really nice to have so many people that know far more about asynchronous and synchronous uh composability than I do um and so I'm just really excited to to speak with all of you um maybe we could do a round of of intros uh starting with s hey everybody andream uh I was formerly professor at the University of Washington Seattle and I run a project called igen L which allows anybody to stake and use the security for arbitrating your protocols awesome and then zachi probably needs no introduction but can give one anyway sure uh Zaki co-founder of inclusion defi protocol called simier I've done some other things cool uh Ben yeah I'm Ben uh I'm the uh CEO and co-founder of espresso systems uh we're working on shared sequencing and base rooll up Sol soltions for um for sharing liquidity across chains so this is very relevant panel cool and then uh yeah last but not least IIA um hi am IIA co-founder of near uh near started as asynchronous sharded blockchain and now Pioneer in chain obstruction awesome so I think that's a good way or a good place to start maybe we could go through and each of you could just give your view on the necessity of syn composability I think we'll we'll have some like maybe different views but uh but Ben I I I know that espresso is super focused on shared sequencing one of the superpowers of shared sequencing is enabling synchronous composability in in different forms and so so maybe you could just give your view on synchronous composability whether it's required and and like what it provides right uh I mean I think and I and I think synchronous composability is uh you know maybe the the holy Gra or far end of the composability spectrum and there's also forms of composability that that are that are not perfectly uh you know we might call synchronous composability which are already useful um but in general the value uh I I think that the value of ethereum is the fact that it is one system and the fact I think the value in any blockchain is it's is is its is its global scale the fact that if you build an application and I build an application these applications can talk to each other and that's very much what distinguishes it um at a user level from web 2 I mean of course there's a security element as well but in terms of the utility of web 3 it's been the fact that it can get so many different people to trust one system where all these different applications are are pluggable with each other um and so if if we if we're trying to scale uh blockchains we want to retain that utility um and synchronous comp compability is the you know Holy Grail of of of composability the idea that uh a single transaction could do things in your application and my application um that are all dependent on each other it could move assets from one to another we could do things like flash loans Etc uh but there are also weaker forms of composability that are already very useful okay um maybe saki do do you have a view I wanted to go do something first which I was I think we should try and Define synchronous an asyncronous composability without assuming anyone knows what they we're talking about maybe I I'll give like a concrete example of these things so synchronous composability is like um anytime you like let's say you like there like let's say you've used instadp InStep is a great example synchronous composability app it has these things called zaps um and you can like uh you know take a position like uh like move from let's say like lending on a to uh uh I don't know the igen layer deposit contract in like one transaction and it'll swap for you through Unis Swap and the whole thing will automically succeed or fail right so you get this property of like atomicity and like it's very familiar to every crypto user like you go you see you do your transaction you get the transaction ID you plug it into either scan or another block Explorer it tells you it gives you maybe a comprehensible error message message if it was if it didn't go wrong but this is your user experience um if you've used something like squid router or uh like ibcf fund uh in the cosmos ecosystem uh you'll have like the experience of async composability so there's like a set of transactions that get strung together uh maybe you don't have to do all of these transactions yourself um we've gotten better at that but they could fail independently like you're you could start an IBC transaction uh but it could time out in the middle uh or you could there couldn't be enough liquidity and your coins might not return to like the blockchain you started out with but they might end up on like another blockchain um so this is like the the common experience of of these things uh so you know earlier work I worked on a asynchronous composability system called IBC for several years um it's widely deployed it moves billions of dollars um then I worked on uh a an cross like a multi-chain defi system called similer and I don't want to go into the details of it but it does very sophisticated things like uh our vaults are like the biggest liquidity provider for rap Stak eth uh today uh which is and it's like this complicated cross chain system that does it and at the time when we started building it we could only have thought of building something like that on ethereum synchronous um but just in the last week we launched on multiple l2s um with similer and then soon we're going to have vaults that actually uh share liquidity between l2s um and we thought when we started we didn't know how to do this um but we're two years in to having these things uh to working on this project and we were about a year into up being in production and as we've gotten more experience um we've actually learned how to deal with asynchron pretty well now we have to Cobble together these systems like our uh our cross chain system has IBC Axel GMP uh ccip and intense in it um which is kind of ridiculous um but like and like that part of the process is like more painful to us than asynchrony at this point that makes sense yeah it's a good uh good starting point with with definitions um uh stream how uh how do you feel about synchronous composability yeah you know Zaki defend synchronous and asynchronous composability I'm going to go down one more level and just Define compossibility um the the the thing is I think there are different uh when we're thinking about composability I just want to bring back one one aspect which is what is the trust model for composition and you know there are many many different trust models that one can one can think about when you're composing which is using multiple systems together and the the the weakest trust model or you know the starting point of the trust model would be something like I have two domains and I want to kind of do actions on these domains or two applications and I want to do actions on these two applications each of them maybe they're living on a on a chain so and to compose this now I'm using a third actor called a bridge and the bridge is now helping me move information or assets across these two in this model now the trust is the worst of the sending domain the receiving domain and the and the bridge and then you can go to one level a trust minimized which would be then say Oh I don't have an intermediate actor and IBC is like this which Zaki and other Pion and IBC is like oh you know if if this if both the domains are safe then your transactions are safe right so you don't need to rely on a third actor and so in in this kind of like a composition the trust assumption is that this this might happen so the the trust assumptions on composition are in a separate Dimension from synchronous or asynchronous composability so I just want to kind of bring out this Dimension here and you know in in something like IBC you are basically trusting both the domains to be safe and then when you compose across multiple apps you may be taking trust assumptions across many many different trust zones so you are only as secure as the weakest of the trust zones that you're touching now you know what is even more trust minimized than this is to have if all of these different zones are identical if they all depend on exactly the same trust assumption then you know the weaker of all of them is still the same thing and that happens when for example uh you have things like layer twos you have layer twos on top of a common blockchain then they all move together on a common underlying substrate and they're all verified and validated together and what this does is to provide you know trust minimized composition or you know you could say trustless composition basically all of them are correct or you know invalidated and there is no way for the systems to desynchronize so normally when you think of like composing you have this problem that these two zones you can think of them as two trains kind of running in parallel tracks these two chains moving along and um you know when one of them you on a bridge is basically like this like rigid thing connecting these two like moving trains right it's and what could happen is one of them desynchronizes which means they fork or you know something happens then the rigid object connecting it can just break so you know that's that's a kind of a mental model for the trust model of using you know a bridge to compose between these two something like uh you know layer tools on top of a common substrate is basically you have um you have a a train and inside that there are many like people sitting or like many boxes and all of them kind of move together they cannot desynchronize and so this this is just a hierarchy of trust assumptions when we are thinking about composition and I think this is a completely different axis than the time scale of composition right and the time scale of composition Z Already defined synchronous which is actions happen simultaneously automically together or don't and this itself could require additional trust assumptions right so I will have Atomic composition if ABCD EFG holds so just you know the temporal axis and the trust axis two different axis that we need to think about when we thinking about these systems yeah I I think that's really good way to put it I mean certainly it's how we see the agir is like how do we ensure safety uh and Preserve in some sense this trust minimized property um while while massively reducing latency and you know creating the ability to for for adity and so um yeah I mean not to show polygon stuff but but but that vision is like is possible in conjunction with things like shared sequencers like what Ben's working on with relays and Builders and so um but but yeah this panel is not about polygon it's about you guys and so uh Ilia um how do you see obviously like near is very focused on asynchrony and I think that you maybe more than anyone else um have seen sort of like the limitations and the pitfalls of of synchrony and charting and locking and sort of like the cost that some of these system like these systems or or assumptions impose and so it would be really good to get your your view on on a synchrony and synchrony and Trust minimization yeah I think maybe good way to describe it is kind of um if we take ethereum right in ethereum right now it every transaction stops the whole world it's pretty much like when transaction arrives everybody's like okay everybody stop we're gonna process this transaction this is the most important thing and then okay let's move to next transaction right and you know there's 100 gigabytes of State all of that state is locked even if this action processes and touches like one smart contract now salana introduced this idea that actually if you mark up on your transaction which pieces of State you're going to be executing on you can only you can lock only that state and then so you can in theory process in parallel budget sty and there is like techniques how to do it on evm now but that kind of the was the original idea is like if you know what you're going to be touching uh you can lock only that state and then you can use the fact that you have lots of course on your computer and processing in parallel so you can still have in a way the same kind of level of compatibility even though you have uh kind of in you know parallel Computing now the challenge was that you still are limited by what one computer can do however kind of powerful computers are now uh you know it's still kind of okay let's stop the world and process all the transaction that we can on one machine and so kind of our assumption has always been right if we are bringing billions of users there's no single computer that will be able to process that there's no single computer that will be able to even store all of the State uh and transactions that are kind of uh needs to be processed and kind of you know the way this is usually dealt with is by paralyzing uh the execution by paralyzing the state and you know it's called charting now that is naturally you know requires some mechanism of you know uh kind of figuring out how to process things in parallel and and maintain consistency and we have now few like a spectrum of approaches right there's an approach of uh Cosmos which is like hey let's just have a like everything is an independent chain and uh you know they all kind of fully asynchronous and there is a message passing protocol to synchronize kind of when you need to do to communicate you have indeed rollups which I'm described which is kind of like we have like a base synchronization base but they're still running in parallel and like firing in parallel and because right now at least the Cent Frameworks all have very different kind of approach to how you know proofs are settle like the actual like we have this uh kind of lots of like oh can I settle actually this there or I need to wait seven days right and and so there's like few approaches like EG layer and fast finality working with aen layer to actually synchronize that more and give you this like uh some framework there and then the near approach kind of from where we started was well can we have kind of the same thing like if you have you know every smart contract every account actually has independent rollup but we synchronize them every block so we kind of communicate and synchronize every block and so because of this we can do message passing we can do all of the things uh kind of embedded into the system itself and you still have this asynchronicity from perspective every independent account a contract you send a message to somebody else right it's all like uh because they are running on different computers but now you have some guarantees about message delivery consistency and kind of all of the things and so that's kind of the spectrum right and I mean it's really cool to have all of this options because there is like different cases where and different of the options are needed and uh in turn you know you get uh like everybody's working on the Trust minimization on the other side right where like you know Cosmos has also you know how do we do shared security obviously you know ethereum with rollups but also withag ler like how do we do shared security kind of faster finalization and then near kind of provides it on the base layer but I think the biggest benefit though coming back to what Ben mentioned is like we can rely on using other applications without like you know if you usually in web 2 use something and it's built by two you know two people in a garage with a dog like you're probably don't not going to build a billion dollar business on top of it but in crypto you can actually do that because you have this uh kind of trust minimization you have you know kind of smart you know how the smart contct will execute and run now there's a lot of caveats on all of this right you know the upgradability the kind of what is the trust mechanisms between in all of this but I think that's the biggest benefit that we getting in crypto so like for me composability is the biggest benefit we have in crypto uh in in web 3 and and we need to promote that and then just give as many tools as possible to developers to really like connect those things together yeah I think I think that's a really nice way to put it um I'd like to change gears slightly and uh you mentioned ear like sort of some of the instances in which um synchronous composability imposes costs because you're sort of reliant on a single machine and and you have to take locks and um one thing that uh that Justin and Ben helped me understand and learn about is sort of this uh I I I would say this new paradigm where we kind of apply proposer Builder separation to Shared sequencing like my my naive view of of what shared sequencing was was um okay we have some committee and they process all the transactions and and uh they order them and um and that's actually not really the vision for shared sequencing it's uh we have some committee and they auction off slots to Super professionalized like high-capacity Builders and so these Builders can can be running in data centers they're not really constrained computationally and they can actually coordinate synchronous composability across many different chains and domains and so Ben I I I think you're sort of the best person to like dive into that vision and and talk about uh sort of that view where where we don't really give up decentralization but we highly leverage centralization to provide synchronous composability yeah I and I think that uh you know one way to think about is that in any consensus protocol like there's there's two parts right there's a proposer which is acting at least for a moment as a very centralized entity um and it's the one that's like basically doing the execution for everything in this blockchain and creating a proposal and then the security of the blockchain comes from the fact that you have a testers which are you know stamping their approval of what the proposer did and this is going to ensure that the the blockchain doesn't equivocate so whatever was was was proposed doesn't get changed later um and in some cases it's also doing verification although one way to think of rollups is that they like massively distribute the process of creating the information that is needed to verify what was in a proposal and that information doesn't need to be re-executed and verified by everyone um so with shared sequencing we should think of as you know just another mechanism for basically determining who is this proposer I mean even if you have rollups that are each running their own thing if they each have a decentralized protocol it could be the case that there is one proposer who just tries to be the proposer for all of these different rollups and in so doing it's able to create an economic surplus because it can do things that other other proposers that are not coordinated wouldn't be able to do and so a shared sequencing mechanism can be re-envisioned as a shared mechanism for you know in in the most economically efficient way determining who gets to be the proposer uh for producing uh and and sort of coordinating between rollups in each slot and this doesn't have to be fixed forever it can be dynamic and uh we can think of it as a marketplace where by rollups are effectively selling their blocks uh block space through this Marketplace to uh to to biders who are trying to become a shared proposer maybe not for all chains but for a pair of chains um and and so that's yeah pause there but that's sort of the way that I think about it um yeah yeah I think that's like a like a very compelling Vision because we can have like like I I I think in in the world where we don't make usability tradeoffs or we we we don't sacrifice like the experience of using a single chain even in this multi-chain ecosystem like we need probably a decent amount of synchronous composability and I think that this view is one where uh we can actually have that at scale without giving up uh things like security or decentralization um obviously I I think that there are maybe some trade-offs and maybe Zaki or shiram can can speak to those but um I think like for me personally it's like a very cool View and one that's like really complimentary to what we're trying to to achieve at polygon I find I find this Vision like very intriguing like it's very very intriguing because the trade-off between like big like large fat BL blockchains like uh the sort of Monolithic blockchain thesis right it's like yes you're going to go and do most TPS as fast as as but maybe maybe the need for synchronous composability or like the economic surplus of syn synchronous composability like where is it that like it was just massively more Capital efficient to be able to synchronously compose than it would have been to have to asynchronously compose these systems maybe those things are not routine maybe those things happen infrequently maybe you know someone trading nfts over there and someone having a perex over here like those things don't need to interoperate very often um and there's very reason and you know there'll be like a lending market and a spotex and like these things can be independent um and there's lots of opportunities as I think we've seen a lot of experimentation in in in various ecosystems around like optimizing for these things or um uh you know you know we see a lot of prexes in Cosmos these days um and their need for synchronous composability is is infrequent um if if non if not non-existent so the idea of having you know of getting to a world of this like where you have these like um where you have this Marketplace for Block space and you have this like ad hoc composability uh it does seem very uh uh it does seem like a way of having her cake and eating it too my only caveat of it is that like these systems tend to be very complex um um they seem to they tend to be very complex relative to like um Sovereign asynchronous comp asynchronously composable systems or like sharded asynchronously composable systems and I think like the biggest open question is whether or not that economic surplus is large enough to justify the the technical investment um needed to like uh uh bring this sort of ad hoc synchronous composability world uh to life yeah I think that's a fair characterization I do I'd be curious what Ben and and siram and and Ilia think about this but I I do think that the nice thing about this vision is that it degrades sort of gracefully like like if something goes wrong with the builder or uh there's like some issue with the complexity inherent in the system then I I do think it sort of reverts back to functioning without synchronous posibility um but I really like what you said about uh like monolithic chains and um the way that I sort of describe it or like to think about it is like like like like salana is a monolithic train not not to pick on salana but uh on salana you have like onchain games that are contending for shared Resources with like dexes and Flash loones and it it does seem like there's like just this inefficiency that's inherent in that design where where like you like those games are like paying for synchronous composability in some sense when they truly don't have to because they don't need to be like so closely located uh in the sort of composability space to defi Primitives that like actually require composability and and um but yeah I on the question of like complexity and how this Vision uh like holds up when when things go wrong maybe sham and then and then Ben or Ilia I'd be curious about about your views on this yeah I will stick to my uh Dimension trust so when we are uh when we thinking about synchronous composition in in a system like uh what Ben just described which is you know Builders basically coming ad hoc and aggregating multiple block spaces and producing blocks simultaneously so you know when we think about trust here is always the question is trust for whom and you think about it from an end user point of view let's say I want to make a transaction which is synchronous across three chains and atomic and from my viewpoint you know transaction should only fail if these three things happen together now again we can start seeing there is a nice trust Spectrum here the first kind of like a operating Point here would be something like or the Builder makes promise that they are going to make sure that these transactions all happen together right and um this this would be the first you know most trust you know most trust requiring type of atomic composition I trust the Builder the Builder promised me like you know they're going to do it okay then you can go like one level up and then say no actually the Builder has already staked for example you know a certain amount of economic capital and made an assurance that if I ever break my promise so they make actually credible commitments on chain using something like I make a promise that uh I um I'm sticking to my promise and I won't break it and if the amount of economic capital that is you know at stake is higher than the amount of economic value that can be extracted from breaking the promise then you can assume that they're they'll they'll be honest and even if they're not you can slash them and redistribute the money to the injured users so that's another kind of level up on the trust assumptions the highest grade of this trust assumption would be something like the uh AG that polygon's building which is now you know when you're making commitments to the um to each of these chains I actually acquire a lot and submit a ZK proof that I've actually like you know held so it's basically just the same thing which is credible commitments where you make a credible commitment a prior but the commitment is enforced cryptographically rather than crypto economically which is what something like I L to and I think that kind of like sets the kind of trust Spectrum here which is you have this Zone uh the different zones of operation which may be different layer tools for example and then what happens is that uh each of these come together on demand ad hoc you know to when there is the economic surplus that Zaki was pointing out and they come together to make blocks and it's Justified because the cost of making these blocks actually um together uh is worth it right for whatever other reason because at that time there is enough interactions the really nice thing I think from uh my point of view on this is that it is a much more like bottomup U you know U design where you don't have to coordinate a priori you can coordinate a posteriority like when the events to actually coordinate arise you can actually coordinate them but you should have made some kind of pre-arrangement on the coordination mechanism otherwise you will not be able to coordinate at uh post post hog um just adding one more kind of Dimension here which is the uh near uh finality gadget for example that uh you know we are working together on the idea there is you know either you know with the um any of these methods one of the things that you absolutely need is that when you make promises that these are the blocks that need to be built you should not be able to build some other blocks you know directly by bypassing that system so you need a lock that you know when you've sold the blocks that you're actually kind of building in this order they actually get built in that order and I think you know uh there are different ways and different layers in which you can express it and I think that's you know with the the nearest finality layer that we're working together is basically uh just a layer which gives this assurance that yes this is the order in which it'll be returned there and you know you cannot bypass this so yeah so that's that's my quick trust assumption overview on synchronous cool maybe Ilia anything to to add there yeah I think the to kind of add to zaki's point the complexity here is because you have a lot of moving parts that require pretty much kind of build like in a way building another blockchain right to to coordinate that and that's why uh I mean what what shiram was describing if you if you want this uh kind of commitment that this multiple of this rollups will include something like for them to actually commit to that they need to use some something where they will been forced to not be able to publish or turn their block right then that system itself can actually accept the Shar transactions that will will go into all of them uh because like that enforcement can happen there and so you can you kind of like you're moving very clearly toward you know still having like a um a blockchain that coordinates all that and like you know how exactly you design that blockchain is you know obviously various design decisions but um like it becomes that like okay well now everyone who wants to opt into this right they need to pretty much use this blockchain to see if if like somebody bought the space from them include that uh that should be kind of the uh you know the prefix of the block for example you need to have an ability to enforce the execution itself like because I mean the the really important part to understand is that V VM is not designed for multichain I think that's that's a kind of really important and what it means is that let's say you want to do a flash Lo between two different chains the just the address space your message dot sender all of those things don't work really well right and so if you want to do actual like synchronous compossibility between these two domains you need to have somewhere uh not just execution but you need to provide back the outcome of this execution so you need now to have the sequence like the sequencers that presumably if if we have it opin mode right they need to have their own sequencing plus an ability to accept somebody else's not just sequenc but executed transactions with commitment and with uh presumably proofs that this is a correct execution right so there's like a lot of kind of component need to go into this um where you know the alternative is you just say like okay we'll we'll sell the whole block and they just kind of lad it up us again with the full execution proof uh with State Witnesses and kind of all of the things to like include that and so all of that is just like super complicated uh and kind of you end up in a way uh going closer and closer to building like a a kind of a blockchain that you wouldn't need the rollups in um and maybe like maybe there's an architecture that uh is more uh like Optimal for that so like on near for example a lot of the pieces of designs of standards are designed to be multi-chain so like our our token standard is multi-chain by definition you our for example contracts like Unis swab is able to receive messages from other chains because on near any other contract in the way is another chain and so you need some of those details as well to for this to truly work and kind of a more um uh like I would say simpler way and I would say with a carent evm implementation it will like it will become super complicated and we'll have like collisions of addresses and other things that uh you know potentially people will exploit interesting I think I'm not sure I agree but uh Ben maybe you have a different view on like the uh the sort of complexity and um yeah just like how uh difficult it is is how complex it is to to move to like a PBS plus sh sequencing system yeah I mean I think what Ilia is talking about is is more is is more about the I mean the the EV evm itself and whether the evm itself is is set up to just receive messages from each other uh if you have different instances of the evm so I guess what I'm going to comment on is less specific to this I'll let you guys have that debate um and uh more about just you know what is what is the technical complexity of this coordination layer that I'm talking about um and so if you think about rollups on ethereum uh I mean they already are coordinated through ethereum right the model is already that you have ethereum as a coordination layer and so the question is simply how do we improve on top of this right um the the the the solution we have at espresso and it's not that it doesn't have technical complexity to build but it's still within you know this same model if you have many different rollups and they to share some common infrastructure just like they share ethereum for data availability and settlement um they can share a mechanism through which we decide and it's it's a consensus protocol right the results of auctioning off proposal rights for chains so um the the the this is a consensus protocol that also provides what seram was talking about of uh finality over the results of not only who has given proposal rights over different chains but what they proposed in such a way that they cannot equivocate um and so the uh you could just you could use ethereum for this you could in a very naive way just use every ethereum block to you know record this it would just be less efficient so that's why at espresso we have a uh you know a bft side protocol that uh is used in order to determine the outcomes of this and we allow the L1 proposers to Simply participate in this protocol on the side and and this uses I layer raking um but uh you know ultimately you do need to design some kind of again just to summarize you need to design some some kind of uh coordination layer it mean it needs to have you need to have ensus among the rollups on what was the result of this auction um which rollups are proposing for themselves which rollups are have delegated their proposal rights for a given slot to a shared proposer and what was proposed um what what what ended up being proposed uh how can we prevent equivocation on what was proposed that's fundamentally what is required here yeah I think maybe just to because I totally agree with that and that all makes makes sense the question is how do you go from there to actually synchronous compossibility of two for example evm rollups right and I think that's where complicated yeah and so that's where as a special example uh if there's a proposer for two different chains let's say they're within the polygon ecosystem then this proposer for those two different chains can now using the AG layer design start uh as it's constructing the next blocks of both of these chains can cue messages and pass messages between the chains and create proofs and then and then aggregate them at the end and that's why agair beautifully fits in with this model this model provides an ad hoc coordination layer that enables things like AG layer um I think though El I think that and correct me if I'm wrong but you're you're sort of pointing to okay how do we actually design the two chains to receive messages from each other and and pass it between applications and then are there you know is the evm really a um you know designed weal to to do this how complex is that well I would say what you described is perfectly fits with a synchronous uh composability that for example near as well doing but when you say something like I think people expect you know let's say just flash low and say like a canonical example of this um and so you can imagine you know if you have a flesh loan on one uh roll up and then you're trying to swap that flash loan for example you're doing like a triangular uh rebalancing right you're trying to swap on the other one the currently like you need to Overlay pretty much the balances of the account that don't exist on that chain right and so now if you have like you you need the Machinery on the other side to know how to deal with pretty much non-existing uh balances I I don't think that's necessarily needed like for example in the three trust models the simplest trust model is your trust the Builder the Builder actually has awareness of both the chains and the Builder is basically like taking the risk and actually doing the atomic swap you go one level up you the Builder can put up more than enough cash on as to the the um the flash loan and actually go and execute it so the chain State transition functions are themselves unaware of this like external complexity but and then like you know the a layer design would be that uh just to finish this the AG design would be that the the two chains can make progress only if the blocks are simultaneously valid and so that would basically make it that when you also know that there's a joint builder then you get exactly the atomic composition feature that want this Builder is building for both rollups it's building the next block for both rollups together it's executing for both chains and it's it's simply that the the extra complexity is in the fact that you can't just make a a contract call from contract on one chain to the other without passing a message that has a proof attached to it uh and that's where the additional complexity comes from yeah so we we we did get the one minute warning and so I don't want to cut anyone off without like an outro but uh maybe we'll just go really quick like 15 second uh closing thoughts um uh Elia start starting with you yeah I would say like because uh we kind of I think sure I'm touched on that I think there is a approach of intents where as a user you you describe the intent and then you have the blog proposers Builders Searchers whoever else figured out how to deal with it and not actually needing to figure out how exactly transaction is routed across many chains and I think that is how we're going to get to the kind of from a user perspective what user looking for in synchronous composability uh and then like all of the technology we are all building here is infrastructure behind the scenes and users just saying like I want this you know figure it out you know swap between 15 chains if you need to and so that's kind of what we working on is chain abstraction so I'm inviting everyone in Denver to join chain abstraction day awesome shout out to chain abstraction day um Al that's a good name for uh for for the concept train obstruction um yeah I go back to you know the dimension I was always talking about trust you know when you're thinking about composition we need sh trust we need cryptoeconomic trust that's what we're building at Aon l so any of you want Shad security uh or economic trust for doing any of this stuff feel free to reach out cool um Ben any closing thoughts yeah I I think just to Bringing coming back to this uh you know the importance of coordination and the fact that coordination will happen anyway so we should design around it in a way that it's uh you know done to minimize risk because if we have more risk and lack of coordination it is going to lead to more centralization and and pitfalls for users completely agree uh Zaki any uh any closing thoughts I think this was like I I think this is like a kind of a a good survey of of the like issues that like things like the abstraction layer uh chain abstraction uh ink synchronous composability protocols like trying to have like native interoperability more widely in the L2 world are all trying to like get at and it's like we're all trying to kind of figure this out together um uh it's h it is a I think it is probably the most exciting thing happening in La awesome I agree that's a great way to uh to end it but thank you all very much for for being here and uh yeah thanks for the the really nice conversation [Music]