Battle of the Bridges: Untangling the Tradeoffs of Various Bridge Designs | Devcon Bogotá

foreign [Music] I want to introduce our moderator because it's not tarun chitra uh uh this was supposed to be our moderator but we canceled him because he had to leave a little early and instead we have his alt and even bigger brain uh moderator wait where are we Guillermo um Guillermo is I want to introduce Guillermo he is the head of research at bank Capital crypto uh and he also uh is a PhD from Stanford like all these other smart people writes a bunch of research papers and is going to ask us insightful and probing questions to get to the heart of the trade-offs of bridge design and the future of cross-chain communication um so thank you Guillermo for moderating this well thank you for the far too kind intro and in fact because you've said so many nice things about me that's how I know you're full of [ __ ] but it's fine um anyway so yeah so I guess as a first you know let's start with all the big intros is you know we have you three I know two of you quite well Chris unfortunately I don't quite know you so that means I'm going to pick on you to start uh give me a 30-second intro of who are you what do you do what have you done to deserve this and what have you done to be up here what so I'm Chris Winfrey I'm one of the co-founders of hot protocol um so hop is one of the only bridges that hasn't been hacked yet oh spicy closing in on uh three billion dollars in in volume so far um before I was doing hop I was a security auditor um covered projects like opens up one framework auger dydx uh to Central and and a lot more is that correlated with the bridge not being hacked yet or I think so so all right I think Hearts unfortunately you are next sure guys uh I'm heart Lambert I am the co-founder of a protocol called across which is a cross Chain Bridge we'll talk about the design and how it compares to hop and other things shortly run me like this yeah yeah I won't front right here um uh I am also the founder of a protocol called Uma um not this human correlation no relation um although there is a funny story about how Uma heard about Uma early on but we won't go there uh uh but um we are an optimistic Oracle Uma is an optimist Oracle and we use this option to coraco as a security model for a cross which we'll get into um across also hasn't been hacked um so I think congratulations I think yes uh so far at least so far um but we'll we'll talk more about that design pattern or the design trade-offs going forward hi I'm Uma I'm the co-founder of succinct Labs we're a newer project company uh that started just this past summer and we're working on a proof-based bridge so also we can talk about the design uh people also call this a ZK Bridge there's nothing like zero knowledge about it so I like to call it a proof-based bridge and yeah we can just talk about how all the snarks work and how um yeah our bridge is going to work cool so um I guess to start bridges are kind of a fraught area in a lot of ways not just because of the hacks but I mean like you know even definitionally people are like oh like that's a bridge or that's not a bridge or whatever um and there's a bunch of categories of bridges right so um first things first I guess can one of you whoever is feeling the spiciest or at least spicy depending on your day uh describe to me like what are the categories for like what what like there's like an ecosystem of different types of bridges you know there's like succinct bridges that use like ZK the power of ZK trademark uh there are like kind of you know a bunch of other designs so well actually maybe before we even yeah so let's let's set the definitions first can anyone give me like how these Bridges separate into like their respective categories so to speak I mean I'll shoot and go and say it and I think you can broadly create like talk about asset Bridges bridges for bringing bridging assets between blockchains and let's call it data Bridges or messaging layers or arbitrary message Bridges which are for bridging data okay our do data Bridges contain acid Bridges as a subcategory or not I think there's I don't I think we could probe that I'm not sure I think it depends on design I'd argue every asset Bridge Is underpinned by a data Bridge okay I would generally argue but there's sort of some nuances because for example a cross uses some of the canonical data bridges too um to bridge assets okay so fine so we've been listening to Bridges and then acid Bridges and you're right I think you could maybe do a subset thing here too with like some caveats or asterix's sure and then on the acid Bridges I think one important um thing to discuss and potentially agree on is dividing them into wrapped asset Bridges or what I sometimes call like lock and mint Bridges where you take an asset you lock it on its uh home blockchain and you mint a representation of it on a destination Chain versus what I will call like um liquidity Bridges where there are canonical versions of the asset on both the source and destination chain and the the bridge here functions almost as a convenience metric or a convenience tool to easily move that asset from one chain to another and Chris I want to see if you in particular agree with this because I think we are both in the category of like liquidity Bridges uh yeah completely agree I think we're both liquidity Bridges and then I think you could even break up each of these categories into a bunch of sub categories because there's you know tons of different uh approaches like snarks the Hub and spoke model and you know the the one that's been kind of the worst in terms of security which is uh multi-sick Bridges [Music] okay so fine so you both chose to be uh what do we call it liquidity based Bridge the liquidity Bridge all right fine uh why not for example a wrapped acid Bridge like does it matter do you care is it an interesting thing so um you know we actually rely on these wrapped asset Bridges to exist so every single roll-up has a wrapped asset bridge and and you you know you deposit into the layer one contract and a representation of that deposit is minted on uh Layer Two so with Roll-Ups you're able to kind of secure the whole wrapped asset Bridge with a smart contract but where we've seen things go wrong is when you have a racked asset bridge that is a multi-sig because racked acid Bridges need to hold a lot more tvl than liquidity Bridges because they're not just holding enough liquidity to kind of facilitate cross training transfers they're actually uh holding all of the liquidity uh of that cross-chain asset and so what liquidity Bridges do is we basically bridge between assets that are produced by wrapped acid Bridges I'll say vertical correctly I think Uma has a spicy take on this well I want to interrupt and put a bit little Nuance in this too because I I want to further differentiate between maybe nuanced types of wrapped asset Bridges so Roll-Ups like Chris's right that when I want to create uh like a version of ethereum on a roll up I'm like locking ethereum on a I'm locking ethon ethereum and producing that version of it on the roll up but I would argue that's not exactly the same type of it's it's different because it's adopting the same security parameters as the roll-up itself and so if you trust the roll up you're fundamentally trusting this supposed wrapped asset so I almost refer to that as like the native version of that asset on the roll up the type of wrapped asset bridge that I think Chris is [ __ ] on and I totally agree um is the one where you literally do just like take the wrapped asset lock an ethereum and then there's like an oracle or like a different security method that's potentially super insecure that's minting your representation that on your destination chain and then for the user of that asset on that destination chain that user has Perpetual risk to the security of that Oracle in perpetuity and if that ever breaks that user that just thought they held this valid asset and left with a donut and those are the designs that I think are really dangerous and not cool so sorry yeah I think your point of these minting Bridges having more value locked up in them uh I like to think of it as basically if you're minting if you're a minting bridge you have the integral of all the volume that's passed through your Bridge whereas if you're a liquidity Bridge you're going to have the derivative because at any moment in time you only need what's going to be in flight and so I think it's actually like a much more elegant solution uh to to the problem because you don't have this huge honey pot sitting there that's like waiting to be attacked and even if it is attacked in liquidity Bridge that's bad but it's not as bad because you just have the instantaneous liquidity you need cool okay so I don't have I don't think I have any additional questions about the specifics of liquidity Bridges I will have additional questions which we'll start right now about um what is your liquidity Bridge like how do you describe it what is the architecture how does one construct it like what is this thing sure so with hop we we've kind of come up with this like Hub and spoke model where uh we use ethereum to pass messages between um different networks so these are layer twos or side chains like polygon or gnosis chain and so we leverage each of the Native message Bridges so each of these kind of Layer Two networks or side chains has a message Bridge with ethereum where we can send messages and what we do is we actually bundle many messages at the source chain and then we'll miraculize those on chain after you know many messages have been sent we can propagate this message or this Merkle root through layer 1 ethereum to the destination and this is how we can do scalable but but very slow messaging and then we add a liquidity layer on top of that where we have liquidity providers that you know kind of front uh liquidity when a user makes a bridge transfer and then as those uh transfers happen many of them get bundled up the Mercury gets to the destination and then everything is settled and so that's how we're able to bridge across different layer twos in a way that that you know does have the full security of ethereum if you're using optimism and arbitrum and then we're able to actually put these stock gaps between each Network because we have this Hub ethereum contract and this lets us support kind of you know side chains that don't have the full security of ethereum without exposing uh users to the risk of those side chains if they're on a you know a true roll-up so essentially but hop only allows you to do layer two two layer two transfers or like anything with where you have a you know one kind of consensus layer a truth layer so to speak that's kind of below it so hop can support any Network that has a message Bridge with ethereum okay yeah okay um heart tell us about so yeah there's there's a lot of similarities and then some important differences so across actually only supports uh chains that have a native asset Bridge with ethereum so what a cross does is we actually only have a single liquidity pool of the protocol the way to think about it is the protocol is effectively the settlement layer so you have a single liquidity pool and the protocol will send assets from that liquidity pool to various spoke uh destinations um that can be slow that can be painful that can actually be quite costly so what across does is we have a a third-party actor we call a relayer and so if Uma wants to move assets from one chain to another this relay will effectively front them Capital they'll they'll front they'll send the assets uh immediately so very quickly to them on the destination chain and then it'll request to be repaid optimistically from the liquidity Network in the protocol and so the advantages of this is we since the protocol is kind of continuously rebalancing its liquidity between its hubs and spokes we like to think of this as a very Capital efficient design where we're trying to use as little Capital as possible to do as much volume as we can and kanada uma's earlier point the sort of thesis here is less tvl better per unit of volume so the more Capital efficient you can have not only are like fees lower um you know tvl has a cost of capital cost of capital you gotta pay for so if you have less TVO you have lower fees um but also you have less security risk there's just less of a Honeypot so essentially in your case the protocol and the relayers themselves kind of act as like market makers right you know they are taking on some like Risk in like kind of doing this optimistic like fronting there's no like so the the relayers are effectively making like two-hour loans right um but that is risk right there's risk like there's different it's not really like Market risk they don't have risk to like the price of ethereum going up or down type thing um uh if they're sorry I should be clear if you're denominating your if you're holding that ethereum and you're not planning on selling it if you think of it as like stuff you own you're not taking risk you're making a loan in this in this asset sure right and like roughly speaking but it's I still should be compensated right like in some sense it's ethereum that I don't have that I could just like sell or do something with how am I being compensated for doing that yes you charge a small fee okay so it's basically like you charge like a two-bit fee on this uh this loan two bips over two hours annualizes to a very healthy return and again there's ways where this could be a more competitive it could be auctions or whatever else the other thing that's kind of interesting about our relayer design is the relayers um they get to choose where they get paid back so for example a relayer if Uma was moving assets from arbitrary optimism the realer could ask it paid back on polygon so a kind of interesting feature of the design is if the relayer is like a market maker or kind of the person that's generally doing arbitrage-like things they could actually get paid to move their assets potentially to a chain where they wanted them just kind of interesting interesting okay okay and then I guess we have a bit of a less economic current Focus Uma but a very interesting you know bridge design yeah I think our Bridge um or what's the Sanctus building is not a liquidity layer it's not even necessarily like a token or asset bridge I think uh we're starting off by really focusing on the arbitrary message passing part so I think that's like a big difference uh the high level design is basically similar to IBC how you have like a light client running in the execution layer of a Target chain for a source chain once you have that light client for a source chain running in the execution layer of the target chain then you have access to the source chain State similar to how you guys I guess use like your the you propagate the Merkel route to send a message here if you have like ethereum's state route on gnosis chain then you can prove things about like oh stuff happened on ethereum so you could have a arbitrary message Bridge contract on ethereum that users send contract calls to and then a relayer would send a proof uh on notices chain for example that like oh this message was sent on ethereum and now you should like execute this corresponding message on gnosis and so when you have arbitrary message passing or arbitrary data passing of course on top of that you can build a token Bridge you can build a liquidity layer you can build all this stuff but yeah I think our main focus is basically on making this like trust minimized cross-chain communication layer to start on the topic of trust minimization which I suspect you have at least some opinions of um maybe unclear um so first things first how does trust affect kind of the safety of a bridge A and B uh you know kind of the maybe like higher maybe mid-width question is uh can you make a safe Bridge right like can you like let's Bridges seem fairly complicated in some way or another you know it's like a lot of moving Parts potentially you're dealing with like many distributed systems um Can is it possible to make a safe Bridge or are you just are we all just like kind of screwed like is it just like this like you know sofian task of pushing a boulder up a hill repeatedly just to have it hacked or something yeah I think the trust assumptions are really important so currently most bridges have basically like a multi-sig or a multi-sig in some form trust assumption and so that's really bad because of course for something like ethereum where you have many many validators and a ton of Economic Security your multi-sig is never going to have the same amount of security so I think the trust assumptions are really important and if we can basically have a bridge out of ethereum that has ethereum's level of security securing it which in a light client you can have if you're verifying ethereum's consensus in the execution layer of another chain you can okay so it's actually a little more nuanced you're not getting all the way there but you're getting significantly more there than having a multi-sig I think that's a huge Improvement in terms of the trust model of a bridge and I think that's really important I think of course with a lot of bridge hacks there's some Bridge hacks that have been based on the trust model so like there's been some Bridge hacks with a multi-sig where they actually compromise like the multi-stick signer keys and so that's an illustration of oh the multi-sig is very insecure there's a lot of other Bridge hacks which are just smart contract hacks or like smart contract bugs those of course it doesn't matter what the trust model was like you know for example uh the most best snark based approach could also have Smart contract risk um and so I think it's really important to like be intellectually honest that there's risk in both dimensions like there's risk in the trust model there's also smart contract implementation risk how do we reduce smart culture good like implementation risk like do we what do we do formally verify everything do we just go and like add in a bunch of stuff and say like solidity sucks and we go and like write a new language that is like rust or whatever I mean Guillermo you're the crypto researcher I mean I I don't I'm like a fake researcher I mostly do like a bunch of weird math but I can pretend no I mean I think look I think that's a whole other uh panel or conference wide topic of like how do you write but I'm gonna make you give me your two minute uh sorry what do you do you write down the moderator so I can make it yeah I think you do all the things right you um you have really good Engineers that are smart and thoughtful okay step one you audit your code from credible Auditors or you are an auditor and you still hire Auditors so it feels like an unfair Advantage right that's fine all right but uh you audit your code uh formally verifying your code that seems like a great idea right but formal verification it has its own trade-offs I think of understanding that and writing the rule set actually Chris might have opinions on that too then bugging money program right and then you also just like you you last like part of the reason why you gotta like time the the more surf the longer you survive I truly believe the more credible your product is um because it is very antagonistic environment out there and so just surviving I think is uh is is increasingly uh it just means you're you're more the longer you survive the more likely you are to survive in my opinion yeah I think there are other smart contracts out there on ethereum that are much much much more complicated than a bridge for example I think if you look at the maker smart contracts or the compound smart contracts compared to a bridge smart contract it's much more complicated there's much more moving pieces and people have seemed you know of course those things have bugs too but like people have seemed to figure out ways to make these smart contracts in ways that are you know bug minimized or like not catastrophic and so I don't think they're theoretically seems like oh it should be impossible to make a secure bridge I actually it's maybe even a good question why hasn't it been done until now because in my opinion it's not even the most complex smart contracts out there you probably have opinions on this Chris I I completely agree I I think those are you know both great answers like we need to build up our lindiness uh to you know as as Bridges exist for longer and longer without being hacked the you know the more uh we can trust them to not be hacked in the future um but you know one thing I wanted to really hammer on which you touched on it's if you're using a trusted Bridge you're not just trusting whoever these parties are you know it might be you know sequoia or a16z that's holding this key but you know what we've seen is that over a billion dollars has been hacked from multi-sig Bridges and it's not that these parties are just like turning malicious and running away with the money you're trusting these people to have world-class security this is not just you know average everyday hackers that are that are going after these Bridges this is you know so it's nation state level actors you know like North Korea's Lazarus group they are trying to insert employees into your company they are you know uh doing supply chain attacks where you know introducing uh vulnerabilities like deep down into your software uh stack so you know in terms of trust model it's just you really want to rely on the smart contracts themselves for your security yeah like I mean again let's emphasize the trustlessness and permissionlessness are like they're not really features they're requirements ultimately and again if if you just want to trust somebody then like you don't need a bridge you just use binance as your Bridge right and like fine my favorite bridges coinbase yeah it look works right if that's what you want right and I think the the other angle to look at this too from the multi-sig angle is also censorship um and Regulatory issues and like wait can that bridge even get shut down because someone says Hey a government says hey don't do this anymore you know yeah I think as the regulatory landscape gets more and more like strict having the multi-sig is going to really be tough just from like a regulatory perspective and I think that's why like the snark approach or this proof-based approach where it's like for these like clients you know theoretically anyone can generate the proof anyone can send the proof to the smart contract on the other side anyone can relay a message and it's like truly uncensorable it's like we're going to be very very important remember one thing one thing you said earlier was that your approach is trust minimized but I'm kind of curious why you said that and not trustless because it does seem conceptually trustless to me yeah I think trustless is like a really strong term and a lot of people have a lot of feelings about it uh so yeah we try to be aware of that I think it's trust minimized because ultimately you're still trusting the consensus of the other chains so for example if you know okay ethereum has really good security Economic Security but say I'm bridging from another chain back into ethereum and say that chain only has you know 10 million dollars of Economic Security uh I think it's you know it's not trustless you're still trusting the other chains of validators um fair enough so essentially kind of the way I can summarize this latter part of the panel is that like smart contract security anything that's unsafe is just cope right like you are like if you're just you're just not you're just doing it wrong if you just like have I mean right like you were mentioning right maker Dao is like this massive set of contracts and like I don't know has it been hacked as far as I know no like so I mean what is your perspective on this like how do you make smart contracts secure more generally I asked this question so I'm going to put you under that um but sorry it's just happening sure no um so actually so the most num in terms of number of bridge hacks has uh been just regular smart contract vulnerabilities and yeah there is no reason for these vulnerabilities to be Bridge specific you know a lot of them are signature based um or some of them are just you know regular smart contract bugs and so when when we design smart contracts we design them in a way that makes it easier easy for an auditor to look at the code and uh verify our security variants so you know these security and variants are you know if if a token um kind of like starts a transfer here is it going to be completed here can you know multiple completions happen at the destination uh is there some other way for for someone to kind of like extract value from the bridge um and so if we can you know basically uh make it as simple as possible to to uh verify those things the the easier it is for Auditors to kind of catch any bugs that might show up essentially like what you're proposing is well simplification for sure but also some notion of formal verification or is that not actually it I think there's cheaper ways or more cost effective ways to to get security than than formal verification okay and I guess as a follow-up question what does it feel like every bridge has been hacked and not like every smart D5 contract has been hacked is it just like a bridge specific thing is it just like everyone decides to hop on a bridge and be like oh this is cool like we're just gonna like put a lot of money in here like what what is it like it feels that way because it's kind of true um and honestly I think it's because it's a new market and it's a it's a you know there's a big opportunity and so a lot of people are kind of just jumping in a little too fast Auditors were very very constrained during the bull market so it was like really hard and really expensive to book a good auditor and but people still wanted to be you know in that market early and and so we saw a lot of them get hacked yeah I guess I'd say like Chris Kirkman if I'm wrong but I think all the hacks are actually smart contract tax right like all of them none of them have been no I think some one of them the oxy Bridge was a multi like they compromised the keys sure so I I should say that yeah okay fine multi-say compromise the keys but in terms of like um like your trust model our trust model this optimistic trust model that hasn't been the source of those hacks yet right yeah so the the uh in terms of value lost um it's been key compromises and then in terms of number of hacks it's been smart contract vulnerabilities interesting okay and so with that you know it kind of like we're taking a little bit of a digression here but I'm curious so do you think the bridge space is like fundamentally a Cooperative space or do you think it's very much a winner takes all space in your case and what would the winner look like I mean I guess if you knew you would already be building it but or maybe you are building it but like fundamentally it feels like to me but you know a bunch of people are building bridges right now but really like kind of you know if you build a good Bridge there's the best bridge and that's kind of it like it feels like there's like a metric by which we can measure Bridges and be like this is the best damn thing possible anything else sucks we're just going to use that wait you I don't know that there is a single metric you can look at bridges on like let's talk about acid bridges for a second here where you want like there you want three things you want to be fast you want it to be cheap and you want it to be secure and so I want those three things give me Max of all of those right sure um and so I I think that it's not necessarily clear that that's going to and maybe you want permissionlessness too I'd add that in there maybe that's in security so like look I think on the asset bridging uh it's going to be very price competitive asset Bridging the the kind of the model here is fees how much fees are you taking well maintaining a minimum level of security and that minimum level of security should be like really [ __ ] high because you find language um um I think it's okay yeah trustless and all that yeah thanks we're all adults here but um uh so I I think that's that's kind of interesting like and I think Chris we can talk about this like acid Bridges it is going to be very competitive it's great for the consumer by the way right um but then I think the other thing we can go into is talking about like data Bridges I find it really interesting how you even charge for that or like what the fee model should be and I also don't think that's at all figured out yet um either but maybe go yeah I agree um you know for an end user the the risk for a bridge is act at least for a liquidity Bridge the risk is actually really really low um you're only exposed to a bridge for for the brief period that you're crossing the bridge and then you're you're out and so you know in terms of security it's really um or in terms of cost you know it it comes down to like uh how secure you are and how much you're going to have to pay for liquidity and the more secure you are the less you'll have to pay um for your security and the cheaper it is going to be for end users but end users don't need to think uh too much about the security of the bridge because they have such limited uh exposure yeah yeah yeah I think for users like end user token Bridges have slightly different desired properties than for example a data Bridge that's maybe transmitting like governance results or like other actions on you know ethereum broadcasts out or vice versa so I actually don't think it is like one number to optimize that function that depends on like who your user is like if your user is a consumer they're going to care about different things versus like a dow versus you know whoever else it's going to be so I guess well I just wouldn't add one other thing around this so like your question was is there like a winner takes all Market here and on the one other concept that I think is worth floating here is this idea of it around Capital efficiency where if say for example your Bridge had required 20 million dollars of tvl but could do like a billion dollars of volume a day and you were able to charge like a basis point on that even if that 20 million dollars gets hacked or whatever there's probably still a reasonable model in there like business model where the the the profit of the bridge it was worth the risk of that capital and so again I think the space here where I think the bridge space has kind of gone in the wrong direction is like locking up lots and lots of dollars which is for for well also not making that much revenue and like that's us that's you got the ratio the wrong way around right and so a winner tick all thing I don't actually think this is a winner takes all Market on the asset side I think that um being able to do a low volume thing with minimal tvl like lots of capital efficiency I feel like that will be competitive maybe not again Winner Takes all um and then on the data side again I I think some of the ZK stuff that Emma's working on gets more and more compelling and interesting but I'm also I don't know do you think there's been a winner take all on the data side well I think of course I'm a snark Maxi and I want us to I want all day to transfer to go through you know the succinct like clients the succinct you know message Bridge um you know whether that'll happen I I think it's hard to reason about I do think uh one thing I will say is I think this like snark based approach for assisting to like clients and proof of consensus is kind of going to be the end design of like a data Bridge especially where if you for example if you like don't necessarily care a ton about latency like I don't you know and maybe you can layer a liquidity Network on top of it eventually but I think the snark based approach is technically feasible like it works today we just need to do some more engineering and do Implement proof of consensus for all the chains and just implement it but it works today and it's you know I think it is like the end design like I don't necessarily think you can do much better in terms of a trust model yeah I think we'll probably see a power law distribution like a lot of other markets um and the other thing we haven't talked about is you know there's a lot of assets out there and it's hard for liquidity Bridges to support long tail assets because you don't want to just like maintain the liquidity for for an asset that no one's using to bridge right and then there's also going to be longer tail networks in terms of uh what's supported so you know we'll probably see um you know bridges that are kind of further down that power lot that they'll probably attack the longer tail assets the longer tail networks where they can gain market share and and the the bridges that are kind of at the top uh they're going to be focused more on security and and uh making sure that their LPS don't need to uh be paid a ton so um I'll bring it back really quickly to the original question the reason I asked this is you know in a lot of ways what are you paying for when you are like you know giving a fee to somebody is you're paying partially for the fact that like that thing incurs a risk right so in some sense like security and economic efficiency are like highly correlated so you can think of them almost as like one single number right like I don't think you actually do better by being less secure and economic in terms of economic efficiency or at least not a lot better right um so this is this is where this is where the question comes in which is you know in some sense right if you have like the maximally secure Bridge like it's very likely that it's also the most economically efficient Bridge uh and if not I mean like maybe not is it is that the case like do you think that there could be like you could like somehow lose security but still have people not pay very much for like the privilege of like you know bridging their assets yes I I think there's actually three costs so that there's gas costs um there's time value money and then there's the risk that that that um money is taking Beyond just uh you know a riskless uh feat yeah so I'm gonna I'm gonna make the simplifying assumption here that gas costs are are you know with magical scaling results going to zero so let's pretend on our magical fairy world at scaling as we've seen like 70 talks on are all perfect and beautiful and we get like approximately zero or negligible costs that would be great for the snark-based bridge that would be great in a lot of ways we're waiting for that future yeah yeah and so it actually becomes a really complicated question like I don't think we could uh you know get all the way to the bottom of capital efficiency here on stage um really there's because uh you know both both across and hop have both active liquidity and passive liquidity uh there's different challenge periods so that gives you know different trade-offs between um you know what these different liquidity providers are are um kind of taking on um and then yeah there's also uh you know different just different models in terms of you know how things are bridged so you know with hop you know you can kind of think uh we kind of think of capital efficiency in like three buckets um so we we have like the active liquidity provider um that uh Cycles every 24 hours we keep very long challenge periods because we think it's important to have like a human response if if things go wrong like you that your team needs to be notified you need boots on the ground and and you know be able to know that if your infrastructure is down you can have your engineers get it back up and and protect your Bridge um and then there's the the passive liquidity providers and so hop uses this amm model that we haven't talked about yet and so we we have this like intermediary accounting asset and we're able to kind of shorten the challenge period from an optimistic roll up from seven days to one day and so that that's our 24 hour challenge period And so you can kind of think of the amm look liquidity as as just taking on the seven day uh Capital lockup only for the net flow not the total flow right this is what Uma was mentioning as well right in some sense you can think about it as the derivative of the flow as opposed to like you know the integral over all of it but sorry okay yeah and and so and so that's partially the amms but also partially you know arbitragers and AMS are really that's where they're taking on the seven day of the net flow and then the amms themselves uh that kind of scales to transfer size but not transfer volume so you know we could have a bridge that that has uh two amms that have 10 million uh tvl each and you know that's going to be able to support pretty large transfers very efficiently but that can scale up to you know virtually any volume uh as long as the transfer sizes are are you know below what a 10 million dollar pool could handle so I guess for just for a little bit more context so here the automated Market maker is acting as a way of so if I let's say I I don't know I have eth and I want to get like whatever wbtc on some Layer Two I can instead of kind of bridging eth and then swapping it I can just directly kind of like Bridge swap uh in is that correct or yeah okay so because I'm still on unclear also um I guess before we kind of get to that for context we're talking about so there's two layers here that we have right one of them is like the data layer which is kind of what we were talking about previously and what security models we have and there's kind of like the economic layer where we're talking about economic efficiency that kind of is built on top of like a messaging layer that you can trust right and I want to make keep these two things separate so now we're right now we're talking about like the thing built on top of like how do you transfer assets correctly and how do you like ensure that you can verify that these houses have been put into one's applied and whatever um so let's while we're on that specific topic afterwards we'll get to the messaging part which I think Uma is uh has some other spicy takes on but um okay so but anyway so sorry describe this amm design or like what what is the point of this automated Market maker I guess at the end of the day sure so so uh the the main purpose is actually to one kind of uh price liquidity flows between different networks um and then it also you know there's no way if you're just using the canonical assets to to not take on that that full seven day uh lock up for the the total flow of of assets and so because we have um we basically have this uh intermediary accounting assets so it's like a h token got it got it so you can essentially pay to reduce the risk so like let's say you're waiting 24 hours I can be like I'm gonna Swap this on some exchange right which lets me actually have the native acid and someone else can take on the risk basically we can exit our these H tokens in 24 hours versus the canonical assets um that are exited in in uh seven days and you know so it's like eight Chief eth is the pair and it's basically a market between the the uh 24-hour exit time in the seven days got it got it got it so essentially prices the risk that you are taking on by waiting whatever seven days to interrupt your asset versus 24 hours like yeah as well as uh demand flows between that's right that's right that's right yeah the thing I'm just going to add just maybe zoom out a little bit um like our take across this take is that there is this is a financial engineering problem like if you solve the data uh and solve the data message you have a financial engineering problem and I think the more Innovative you can be with your financial engineering the more Capital efficient you can be right um and so you know again hopping across share a lot of philosophies the the one thing that we've done that is quite different is we don't have these amms at all instead we are actually just having this single unified liquidity pool and we're using the native Bridges to kind of rebalance assets between this Hub and spoke model and if I'm going to like shill our product a little bit the one the one thing that I kind of like about this is I think that that liquidity model allows us to be a bit more Capital efficient than having amm pools that have to be kind of rebalanced off chain um yeah so so like I said the the amms um it's only based on uh transfer size they just need to scale the transfer size not transfer volume so even you know if if we were to have just like 2 million dollars in each amm you know we could support you know unlimited volume if as long as you know the transfer sizes are below that threshold then arbitrages are coming in and and are being that out and balanced you need like yeah I'm gonna push back a little bit because you need the flows to go both directions right if I keep on pushing right in the direction you're going to run out of liquidity or make it an ordinary expensive and that's why I say that that um you know hops Casa capital is you know for the arbitragers it's it's just seven days of the net flow so if you know there's a perfectly balanced flow between arbitrim and optimism um we don't need arbitragers at all okay yeah and it's like this Concepts again like call it like basic basic Financial engineering Concepts or like Market making Concepts is if you can cross flow like if you got a million dollars going this way and you had a million going so I was going the other way it's beautiful and not only that but it means you have like really low costs you don't have to rebalance things just did it all works out beautifully and so again I think a lot of the financial engineering is how can you get how can you incentivize netflows and or have a low cost when there are imbalance flows have the lowest cost of capital and uh there's lots of like fun Financial engineering tricks in that I think but let's maybe go to it so so next up is you know fine so let's go back so when let's we've taken this first part right let's like zoom out and go to the second part which is uh honestly what underpins the entire Financial infrastructure you guys are talking about uh and it is okay so now I ask you the question of do you think that data Bridges will themselves all kind of monopol go into like one single data Bridge right like why not you know kind of why doesn't this become finite like just like standard infrastructure that's open source that's just like classic normal everyone uses it how does one even monetize this thing um you know for example IBC works pretty damn great right and like the idea would be IBC for like ethereum at L would be very cool and obviously that's kind of what you're working on but how does one monetize that I mean IBC is just I just implement the Ping and then that's the standard yeah I think what we're building at succinct is going to be like open source and we view it as like a public good because it is like a public good for all these ecosystems to have these succinct like clients and have this like snark proof of consensus um for the consensus algorithms and honestly it goes beyond just having a bridge like you can imagine this actually being really useful for like like clients and wallets so that you don't have to connect to a centralized RPC and you can like do something peer-to-peer you know something further down the line in my opinion wallets have a lot of other things they need to do before that issue but yeah down the line I think the assisting light clients are important for things even Beyond Bridges um I think yeah that being said so I think we want to build this in a very public goods oriented way but I think you know just because something's a public good doesn't mean that oh it has to make no money like for example operating these succinct like clients is really hard so you know and believe me like I've had to write the infrastructure to you know watch one chain generate the ZK proofs and then set up the infrastructure to Ping a bunch of different like clients on a bunch of different chains and this is not infrastructure that you know it in a timely manner that you know people are going to want to run themselves like probably there's going to be an operator I mean currently us that does this and then has guarantees around it like okay if you're gonna rely on our like client you probably want to you know know that it's going to have like a 99.999 uptime and so I think I really view this as like where what we're building is a public good of course it's going to be open source of course it's going to be audited the more people that can contribute to it and like we can all make sure it's like canonical infrastructure that's really secure and everyone feels really good about but then operationally it's kind of similar to like an open Core Company where if you have something I don't know like in the web 2 world like mongodb where mongodb is open source but you know [ __ ] the company runs the open source infrastructure and so I think a similar business model like could make a lot of sense here where you're basically paying for the convenience and like the Peace of Mind of like you know this infrastructure is actually going to work and it's actually going to be uptime that being said we're not going to always be like our own operator like we don't want to be the only operator for like censorship resistance um and so it's important that anyone can actually run the operator themselves um and yeah I think there's like some interesting things you can like do around that in the future is it possible to tell us but how does one decentralize this I mean it feels hard right like you're kind of relying on someone to reward these things I mean just tell me if I'm wrong but anyone could do this yeah it's just the sense that like this is where no one's going to right other than if you are in some yeah it's like we're going to coordinate all this infrastructure and then you know and we're going to do it the best so you have like the like client that updates the fastest and like you can have like a nice dashboard that's like yes my like client got updated things like that and then in the future I think a lot of the ZK EVMS have been thinking about really similar problems where they really need proofs to be generated but they don't want a centralized prover and so they're going to have like a decentralized prover Network like that's separate from their sequencer and I think a really similar thing could also apply here where you're going to have like a bunch of provers that you know basically I kind of think of it as there's this economic exchange going on where there's people who are relying on those listening to like clients who want proofs and then there's people who are able to provide proofs and there's like some exchange of value and then maybe you have like a Marketplace and you like take some cut of that or something so I guess you know kind of more generally like let's say I want to prove something that happens only once every once in a while right like what incentivizes me from like paying you know this like big pool let's feel feels like what a lot of things like how a lot of things work right like we you know kind of only Bridge or only like send data across kind of chains like very fairly infrequently right so is the assumption that there's going to be like a large enough volume that like people are you know kind of incentivized to always run these things or do we kind of expect every individual user to just like provide their own proofs as needed I don't know how large these proofs even are I mean how long does it take like yeah I think expecting individual users to generate these proofs is totally infeasible like I think to make it you know timely uh you need like custom Hardware probably and like the limit uh generating the proof takes takes a while um how long and then what machine sorry So currently for ethereum our proof of consensus for ethereum takes like four minutes to generate on like a pretty beefy AWS machine I think that time over time that time it takes to generate the proof will definitely Trend um hopefully closer to zero um but you need like GPU or there's a you know a million ZK Hardware companies that I'm sure will use that's going to make it better but again yeah a user is not going to run a ZK fpga in their house like that doesn't make sense Jeremy will yeah yeah gotta minimize that trust you know truly minimize it but yeah the beauty but trusting me I'm just generating the proof for you but the chain is verifying the proof so there's no trust assumption if someone else is generating the proof it's just a sense and the important thing for censorship resistance is that you could generate the proof like you could spend 20 minutes and spin up an AWS machine and generate the proof of yourself and send it to the light client you're generally not going to do that and you're probably willing to pay for the convenience of someone else doing it cool um I guess we are like almost getting down to time uh unless there are any last burning thoughts I think I will turn it over to the audience to see if there are any questions are there any last burning thoughts ideas Notions constructions let's get some questions all right let's open up some questions do you need a uh you first but uh or you can shout and we'll repeat them too hey yes I have a question for Uma uh first one is like what is the time gap for you like to propagate the blocks like like from my understanding like it's working similar to like Rainbow Bridge but like with the case so like you should have like some like gaps like you cannot propagate like every hypnosis chain block to ethereum and like basically like it to any chain to if you're you cannot propagate like every block and like the second question like how much does it cost to like uh well it maintain the like uh relayer like or like validator yeah so the question kind of was how long does it take to propagate a block and presumably you're not propagating every block yeah that's right so uh for us like the block propagation time is first we need to wait for ethereum to finalize uh so that generally takes an expectation around two epochs which is like around 12 minutes and then on top of that we have our proof generation time for the particular block uh so that takes you know another four-ish minutes right now but I think that can go down quite significantly to hopefully someday on the order of seconds um so hopefully that should be no issue and you can probably do things around not having to wait for a finality um that I won't go into now but I think in the future that's also possible um with proof of stake you don't need to propagate every block so in proof of work you actually do because the longest chain is this like sequential thing so you need to verify every single block to verify the chain is the longest but for proof of stake as long as the validator set stays the same you can just send an arbitrary block as long as you have the same validator set and so for us we like send a block you know currently we do it every 10 minutes or something like that um just you know and so there's like an extra 10 minute delay on your Bridge basically um and so there's like a trade-off between how often you want to propagate blocks and the gas costs you're willing to tolerate but if you have like a huge transfer for example that you want to do right now you could like send the block right now yeah I still miss some of this stuff earlier offline but basically it's like 12 to 16 minutes you can send blocks and it costs you like 180k on the destination yeah yeah verifying our proof uh so verifying approved there's like pre-compiles for pairings and so verifying approved takes like 200k ish gas so you have like 200kh Scouts to verify a proof and then you have um like whatever smart contract logic that's should be quite minimal because you generally try to stuff it in the snark um to you know keep the like client up to date and then there's some really really fun things you can do with the recursive snarks so say I'm bridging from gnosis chain polygon and you know whatever other chain and I have proofs of consensus for all of them what I can do we don't do this right now but what we're working on is if you've approved a consensus for three different chains you can actually recursively prove them in one snark and so what happens is you're amortizing the gas costs across all your partners that you're bridging across and so that's really nice because with recursive snarks you can stuff basically and unbalted amount of computation into 180k gas and so I think in the future when everyone starts using this then actually it becomes gas efficient enough you're talking about the proofs proof generalizer for example for ethereum to uh to another but it's I mean it's quite complicated task right to generate State profiling and verify this proof do you have some results in terms of I mean CPU cost or gas cost uh for your for your Bridge because I know it's really complicated and it takes a really long long time permission currently takes four minutes um so it's like on a pretty beefy CPU um and then the gas cost to verify the proof like because it's a succinct proof no matter how much computation you stuff in there it's always going to be like around 200k gas Brian um three quick Rings jeremont like pretty timely comments on IBC you should check Twitter after this it's like a Grim Day for IBC right now um but two other questions um one first there's a lot of new um you know everybody has some new validation method that seems awesome and like there's a bunch of abstract stuff happening here it's new it's better it's great but the majority of almost every system that exists right now still has upgradable contracts where the mutability for that contract basically underlies the security of the system so do you all agree that most of that reduces down to like the trust Assumption of the multi-sig that's controlling the upgradable contract and the second question was for Uma um in a world where like all of the hard Technical Services recursive State Journey you know all of this is perfect and fine is there still this issue of like especially when you're expanding to like very long tail stuff that validator sets actually have clear incentives to be adversarial to each other like there's no reason that validator set shouldn't sign or generate a forged block uh because like imagine competitors um arbitment optimism BNB and polygon or whatever we're like it's actually very strongly in their interest to hurt the other chain yet they have no economic incentive tied to let's say a block of a forked chain that they're presenting is a valid proof um yeah those are my questions let's do the first one first so I I Brian I think we're philosophically aligned like upgradable contracts bad right um and they're they're I think there are things you can do where maybe there's like an upgrade path maybe kind of but generally speaking no no no like make immutable things and that does make your upgrade path very painful right across that V1 and V2 and it sucked it really sucked uh going from V1 to V2 but like you did it and works um and but like again like okay I don't want to shoot on chain link because that gets me in trouble but like there's still a multi-sig behind all this stuff too right and so there are the thing we also have to realize is like indefine in crypto there are these very scary multi-six that are sitting around that could do very bad things and um we I think like Uma spicy take his multi-swicks are bad Chris same like just those are bad like delete multi-6 uh should be the mo yeah I agree um hop is also not upgradable uh we take the the kind of uniswap approach of launching a new version and everyone can still use the old version it's going to exist forever and yeah and then yeah Emma you want to go on well you can you can insult multi-six too that's okay yeah I also think multisigs are bad uh yeah huge props to hop in across for not having a group of great a couple contracts that's huge uh I think for the ZK stuff since it's all like very neat technology honestly for a while there are going to have to be appropriate guard rails um and I think like a lot of the ZK evm teams are thinking through a lot of the problems or like solution potential Solutions including time lock upgrade where you know you can with emergency withdraw and things like that um so I do think it is important to have a balance of like non-upgradable is the goal but when you're working with really new technology like you definitely do have to keep the guardrails in mind uh so I think that's pretty important I think it's definitely a trade-off yeah yeah well and be like it could be a little bit more nuanced than that too like a guard there's there's designs I think that exist where like it's not upgradable but there can be like a way to like a stop button like yeah like an emergency shut off type thing and I think patterns like that are not crazy yeah yeah totally um and then yeah in terms of like the long tail of this stuff okay I think yeah that's a really interesting question so in the long long term if you have a ZK validity proof so right now proof of consensus only proves like header validity but you know with zkevm you could even have state transitionability and then it doesn't matter if the validator's set necessarily goes Rogue because well the validator set can go Rogue and sign a totally invalid block but then if you verify validity proof of the state transition then you're not going to accept it I mean that's very far off in the future um and then it you know if they have like slashing conditions on their own chain then you know they also are subject to that I think if you're trusting if you're using a long tail chain and you're trusting their validator set to not do malicious things like I think if the validator set signs off on some totally incorrect header for their bridge to hurt her competitor I think ultimately they're actually hurting their users a lot more and so to me it seems like just a bad strategy for them to do that like I don't necessarily know if they're super incentivized to do that but I do think it's important like I think for us like that's why we are focusing our initial thing we built is like for ethereum where you know it is actually extremely decentralized they have a ton of Economic Security if you validate ethereum's validators they're not going to go Rogue in this way so I think like that's kind of our initial starting point of focus and again for users of bridges It's always important to remember like if you're bridging between chain a and chain B your securities the minimum of the chains you're bridging between and like you can't get around that no matter how secure your bridge is like if you even have proof of consensus and validity approved um so yeah I think that's always important to remember my question is do you think the user is special for the liquidity Bridge are pricing correctly the risk that the bridge has and if no like what can we do to better educate them I I think if you're a liquidity provider and you're taking on the risk of every single bridge that that um or sorry every single Network that that bridge supports you are an incredibly altruistic person but to your question like I think the users here again to Chris's earlier point the users here are not the ones with at risk um say what the liquidity providers do have risk and pricing that I think is something that is like hard um you know again the lindiness is I think important here too um but you yeah it's hard and again you go back and even when Chris says like okay some of these Roll-Ups are pretty new technologies right um even using the roll-up not even not even being an LP has some not zero and potentially relatively significant risk so like what does it mean to put you know 10 million bucks of eth onto a roll-up that still might not fully have fraud proofs implemented and all that kind of stuff like there we are and that's not an insult I'm just I'm just saying that um we're we're there these are still cutting edge Technologies yeah also under discussed Roll-Ups also have Smart contract Risk by the way like people you know say bridges are so terrible they've gotten all these hacks all there's been all these smart contract hacks and Roll-Ups have the exact same problems like the recent binance hack which was like a Merkel I actually don't know all the technical details but from my understanding it's the Merkle inclusion proof hack like you could have the same thing in a roll-up native bridge too and so that's not to be under under counted absolutely and there have been uh things reported not exploited hey that was awesome and uh I hope this is not too open-ended of a question but do you have any comments on shared validator sets like are kind of being introduced to Cosmos and are in polka dot and how that might affect the architecture of like the proofs that might need to be generated for a bridge I yeah I'm not super familiar with this like shared validator set thing I'd like heard a little bit a bit about it I should probably read more I think as long as you know I think at the highest level basically you can think of like how would a node validate that you know a particular chain has come to consensus even if they have a shared validator set and then ultimately you're taking whatever computation like a node would do and then you're putting that in a snark so there's no like fundamental inability to do this even in the even if you have a shared validator set like you can always do this I mean okay it might be a little harder to keep track of the validator set if it's like rotating across like three different chains or something like that so I'd have to like look more into the details and actually honestly the details here are often what really get you um but theoretically I don't think there should be any like trouble with it yeah I think just the way I would reason about this and again it's not there's a lot of new stuff here and a lot to wrap your head around but the way I'd reason about this is like I figured with Zuma or Guillermo's earlier Point um it's the minimal like what's the lowest common denominator of security you have here and so you know in our like optimistic design all you're doing is saying hey this happened on this other thing you have to trust the initial source and if your shared validator said is better great if it's worse great like you kind of just kind of be sort of dumb about it and be like are you trusting the consensus that this thing is reached I don't think I know enough about shared validator sets to give a good answer all right well with that last question thank you panelists everyone please give a big round of applause