ZKV presents Privacy in Cosmos: Scalability Edition - Bridging and Interoperability Panel

Transcript

yeah i want to now introduce the two other participants of this panel so it's sergey from axelr and zucky from sommelier do you maybe both want to just say a few words about what you work on so that we get some context for what we're going to be talking about uh zucky you go ahead first um so what we're building is i think okay your audio's a little bit funny hopefully you come in okay yeah better yes okay um so my uh uh okay so the um what's what similier is doing is we're using a very similar bridge to the

althea bridge um that is but instead of focusing on the bridging tokens use case we are uh uh um we are doing a thing that is essentially decentralized defy execution um uh and so we are composing uh data sort of validation and instruction validation and custodial functions on the cosmos chain um with the d5 execution on the each side very cool and sergey why don't you tell us a little bit about xlr and maybe how how you see yourself placed in this uh kind of bridge landscape by the way deborah i love that slide and

i'd like to get a copy of that slide with all the bridges that's awesome so just real quick on that that's one kx they did a great job cool really blockchain bridges building networks of crypto networks actually your slides i think some people were asking for it sorry sergey back to you please introduce what you are working on where is um yeah so sergey i work on the actual network which is um you know universal interoperability network and stack to connect uh different blockchain ecosystems including you know proof of work chains proof of stake ibc chains layer ones layer twos and so on and so forth um in general especially and going kind

of back to that slide that you shared there's these different bridge philosophies and i wanted to sort of explore some of these i wanted to understand if there are kind of distinctions between the ways that different bridging or interoperability uh projects are really thinking about how to move tokens and i think sergey as i understood it even from our previous conversation around this like you don't necessarily see yourselves as bridges but rather something else and i'd love to hear that philosophical difference and and why we see it that way yeah so i mean first of all i think the slide does have like some inaccuracies from one kx so uh you know i think happy to talk about those but um i mean on a high level the way we

thought about the problem is that um we just want to scale interoperability right and we kind of went back and thought about how do we do that right and it really comes down to kind of two layers that you have to build in that process one is you have to build basic kind of connectivity layer and allow you to connect ecosystems that speak very different languages right um you know you have sort of avalanche you have solana i'll grant you know ethereum bitcoin networks they all have very different consensus they have very different you know software stacks some of them um have you know instant finality probabilistic finality and so the way we thought about is how

do we make it easier to onboard these new chains right and how do we design a stack to do that and so while we do have you know kind of a bridging i think is a mechanism to do that and there's a technology to do bridging through you know either ibc or um you know kind of a relay and then multisigs or threshold but overall we just thought about how do we make a network that does those functions easier and then on top of it is the second layer which is quite important and i think that's what surf zac is been working on is how do you make it easy for the applications to go cross chain right and interact with these ecosystems and that comes down to building these application layer protocols message pass and routines on top of the

bridging stack effectively right and so we at the axler um kind of focus in both at making a network that makes it easy to build these connections but also the a universal application stack where we're not building an application ourselves but you know we're working with our partners to um to use these messages and pass into to make it easier to to go cross chain essentially and actually thrown into yuzuki like given that you are you are building that in in that kind of strata are there like do you have to make certain decisions of the trade-offs that are like of bridges that are available today do you feel like there are some kind of core

qualities that you know certain bridges already can deliver like i'm kind of wondering like how jelled your decisions are around these bridges so far like do you feel like it's very influx do you feel like you you may uh have already found the solution you're going to stick with so i view what we're doing is building an architecture it's like understanding the goal is to actually understand like like similar is a very frontier application um of cross-chain compatibility um and we are sort of hitting all of the novel problems um that you know other people that you know will be will exist in the future as

other people go down this road um and we are sort of living in dog food in the future um and so yeah i mean our strategy right now has been to sort of you know uh like sort of own the bridge technology ourselves rather than use a solution from some from someone else's ecosystem um specifically because it helps us understand our requirements better um to own the entire stack um whether or not that remains always true is is sort of tbd in my mind um you know there might you know because it is such a it is so painful to speak the languages of all these different uh possible changes like uh

axelr knows very well i can imagine a world in which we just like are like hey like actual art can you just start routing this stuff for us um so like we don't have to be the bridge i could imagine a world in which you know uh you know we reach out to the cosmos ecosystem by ibc much more um that we currently do um yeah owning a bridge is incredibly painful um and uh you know everybody who's on this panel is like well aware of that like insane pain being of owning a bridge um and i think that's one of the virtues of ibc is that it gives you a chain without having to own your own bridge um like the bridge is built in uh but

the uh the the sort of strategy similar is taking is sort of trying to learn how to build what we think is the future of multi-chain applications um uh and trying to build in the president with the tools that are available right now and i think just to add to that right um i think you know zach and their team they're you know pioneers i think in the field right and lesser of geniuses and what they do and i think that's what allows them to own the bridge architecture and build you know a frontier application at the same time but i think as we talk with a lot of the you know folks in the ecosystem they can't really do that right like they don't have the resources dedicated on team or just don't have the technical expertise and i think the way we

approach it is like okay you want to go you know multi-chain you want to cross chain like we can make it easier for you so we could focus on one part of the stack you know you focus on the on the stack that you're good at right then that optimizes the value for your application and use cases because um as like i said i think yeah interoperability is hard you know i think a lot of the folks here also work that like layer ones and other things i think interoperability is like the next set of um challenges that you don't deal with when you're working on a standalone chain and uh layer one got it sorry deborah i just muted you there because there's a bit of echo but feel free to jump in yeah i mean just to kind of give my perspective on

it as well i mean i think it's really about how you value capture the user and how you're interacting with your um you know basically we can think of blockchains as businesses right and if they want to have that integrated and have that part of a vertical more of a vertical integration for whatever their use case is versus having that efficiency of volume by utilizing a shared piece of infrastructure and i think that's just a you know a choice that each blockchain sort of makes depending on how they want to value capture yeah i'm architect i'm architecting the system with the vision of being able to switch our bridge implementation as new technology becomes available cool i have sort of a

very ibc-focused question here which i know is going to come off as a bit naive but you know besides this sort of needing to deal with evm and proof of work there is ivc would it not make sense to try to get more projects more l1s potentially to put their own form of ibc natively that would easily lock into the ibc system has this been tried is there resistance i do realize this is a little bit like potentially naive but i am curious what you think of that um most of the answer there is there is work okay um just significant amount of work um and so that and so i believe the

polka dot ecosystems and the near ecosystems are the ones that we that like there's like a biggest like sort of effective working group around mm-hmm yeah i know that like polka dot there was an ibc the chorus one had something to do with that i don't know who's actually leaving that right now uh there's a team called the octopus network okay um that is actually doing ibc for near ibc for substrate um and also composable.finance is is also working on a on an effort there and this has been going on for like more than a year um and has been like steadily making progress um and so there's uh these are the details that are being

worked out but like you just said oh go ahead sergey sorry i guess actually just to add to that right um i mean i think it is like engineering work um i do think for some change it's like very different work than for other chains so i think like when we started thinking about interoperability it was when we shipped out our ground right i think the first thing we looked at was ibc of course um and algrand has a very kind of a different model for how it elects uh validators for how it elects leaders and so on and so forth and i was like we estimated it would be a nightmare in some sense uh for us to implement ibc at the consensus layer um that being said i think there is also a need to perhaps

decouple ibc right and i think a couple of people have been talking about it um that there's a verification layer and there is a ibc sort of message format layer in some sense right and you can imagine various interoperability or bridging protocols that are responsible for the verification layer so for instance you know you can go through the actual network but on top of it um you can implement sort of ibc packet semantics right um to make it easier for the applications to benefit and compose with other ibc enabled chains and so that's something you know we're looking at internally and i think um yeah it's also important to understand these layers and i think you know we could see ibc packet format i think across the ecosystems which would be

quite interesting but you do have to do you know some translations in the middle you have to have this verification layer which is more efficient as well so the best way i could try and explain this is a lot of the dynamics that come from the authentication layer are like make a big difference between how ibc feels so like right now having this like directly in consensus like client to like client validation layer gives you this property of feeling like that the it's totally permissionless any chain can connect to any other chain um if you try to adapt new authentication layers you're probably

going to give up some aspect of that you're going to give up there's going to be some set of authorities or about some like validator set that is going to have to stand there and be like hey we're going to provide the authentication middleware here um and so you see that with like where zeros work you see that with various other things um that are sort of we see that with axl are all of these things are sort of fellow travelers and that rebuild the authenticational aerospace um but and so like right now though ibc only has a like kind of very boring application which is uh the wrapped token application and so like what makes people think what is ibc is they're like i have this is like the

rap token with this very permissionless bridging uh ecosystem but as we start seeing more complex applications coming out on top of ibc which should happen over the course of this year it might be more valuable to people to be like hey we want to speak the ibc packet format over multiple authentication layers because what we what we value is being able to have like built-in support for things like interchange accounts what are the trade-offs i mean what you just described though like this very permissionless ibc version is there like a downside to that versus something with more authentication besides maybe like what chains you can actually use but more like are there more risks of

for example like you know a tear like a very malicious chain or a corrupted chain sort of bleeding into the rest of the system are those is that is there actually higher risk with something like ibc versus um more permissioned or more i know maybe permission isn't the right word but like a little bit more curated bridging technology i mean i think the big risk i think you know to me is the engineering costs right and the challenges i think that we talked about meaning that it's not just the effort but it's also the maintenance cost right meaning that you know if you let's say you have an upgrade to a consensus mechanism and you integrate it through you know light client let's say verification mechanism um whatever that looks like

um if you're upgrading your consensus you have to figure out how do you upgrade you know like lines on the other chains right so you have this other software um that you're writing in parallel and that's not a you know depending again on the chain it's not a it's not a small piece of software sometimes right that means while the model i think is permissionless you just could have bugs and issues right that you're gonna have to deal with because this integration is complex and you're gonna have to audit it all the time you gotta have to figure out you know how do you upgrade uh correctly so um you know out of all the things that i think um kind of as we thought through this i think the engineering complexities that come to maintaining these things um it's like you have two databases and

you're trying to keep them synchronized right and you do this by uh verifying one one in another through this verification engine which um it's hard to maintain i think in production systems for for some types of connections yeah i would i would just want to echo that as well too i think you get the more generalized you get the more the node infrastructure has to be more robust and the potential for centralization starts happening there as well as you know it becomes more costly um and then you have more issues with you know no infrastructure going down or relayers having issues um whereas you know having a more decentralized approach or i mean lots of bridges is probably a good thing in some in some respects as well um and that you

have redundancy um as well i want to bring up this this sort of topic of role our rollups is out like different chains that are bridged to a single main chain or not i kind of want to talk a little bit about the article or i don't know if it was a blog post or a bunch of tweets that vitalik had sort of raised about you know this idea of a bridged network system versus the roll-up model and one being kind of more or less secure than the other um yeah first of all do people on this panel believe that like roll-ups also use bridges or do you see them as something else

i mean yeah the way that i view it is a roll up is a you know it's a chain of various levels of decentralization with uh with a single bridge by default okay yeah i mean i think the the so the way i think of a rollup is in the ivc version of a bridge we verify the consensus mechanism um of the sending chain um in the in the roll-up version of the of of a bridge you actually verify the state transition function in the bridge but but you you see both as using bridges they're still like the the

actual roll-ups are just blockchains with a bridge that is unique they're just blockades with bridges and is there is there some risk to this like and like it's it would be a weird outcome in my mind if into the roll-up chain the only way like i think it's like a weird one of the weird vitalik assumptions about the world that is like divorced from reality which is you could have roll-ups but it's you could that doesn't mean that most of the assets on the roll-up are going to originate via a bridge that verifies the security of the roll-up okay so like you have hop network for instance that's doing these things onto various

theory ml2s right now and they're just a committee-based bridge into and out of a roll-up basically what you're saying is like because roll-ups themselves can have bridges to external things like you don't like they have the same risk profile as any like l1 bridging to another l1 oh i i don't want like there are benefits to the to the properties of roll-ups that are independent of the way in which you can build this other kind of bridge okay so like it is beneficial to have enough have uh a network that for instance anyone who's running an ethereum l1 client can rebuild the state

from um like that is beneficial independent of whether or not the how the assets were bridged into and out of that asset or that network so it's not like roll-ups are i'm not trying to like i'm not negative about roll-ups i talk to the celestia team about this all the time i just assume that i think it's likely that there will be a lot of committee-based assets originated into roll-ups interesting yeah and we see that as well i think a lot of kind of layer twos and so on and just want to get direct you know integrations with other ecosystems because they cannot you know just bear the cost of going through ethereum for instance right so if you bring in an uh you know to ethereum like you're gonna have to pay huge gas costs that's related with it so they're thinking of

okay can you directly integrate uh with us to be i mean i think the final point i think on that to make um i think the number of different chains it just keeps on growing and i think the users will understand less and less the differences and i think they just care about using the ecosystem more effectively and easier with their assets and just interacting with different applications and i think you know i think it's going to be up to the developers to be to make the best choice of how to deploy an application like what software stack to use and things like that but um i think what users want to see is like i have an asset here's an application let me go and use it and i think we have to work towards that i want to take so we have five minutes

left in this panel and i do want to take a moment to talk a little bit about the theme or kind of general theme of the series which is privacy and cosmos we know scalability we were kind of talking about how to how to think about privacy in the case of bridges i believe we talked about this potentially in the last session as well but you know is are there ways that privacy could be maintained over a bridge from one l1 from one zone to another like is this a space that's been well developed are there already plans maybe in something like xlr like to actually shield projects or shield tokens through the actual bridge technology itself or is it

always going to be a leak so so i think it can play out two ways i think one you can view bridges as a serve a way to potentially you know uh sort of obfuscate some of your transactions right so you can use let's say let's say you're starting from a network that's open right anybody can read the transactions then you can go through um interoperability protocol or bridge to go to a network that has some privacy within it right like secret network or um you know any other zero knowledge proof based networks you can then transact within it um and then you sort of come out on the other end right so you can view it as

serve and mixer oracle in some sense that you can dump your assets in you know mix them up transact and then get them out on the on the other end eventually maybe to a different key okay i think that's one way of doing this um is that not traceable though can you not track what is like in something like axelr is there no ledger that you could actually view is there not something that you you're actually watching these these transactions go through i mean in actually you can but again the goal is you go through you know this bridging mechanism to a network which has full privacy preserving properties right and so that means they're saying you use the you use that like once you're using that new network yeah exactly you're using it as a mixer and then you come out through

the bridge again exactly yeah yeah so from external view you saw okay you you go through you know actual network or whatever bridging you sort of burn your assets in some sense you keep on mixing them and you come out on completely other key right um the key that you specified i think that's one way of doing it and i think the second problem is like how do you make i guess the bridging technology in general like privacy preserve and i think that's definitely you know um a next level of mastery that we're gonna have to get to in order to get there deborah do you have any did you have you done any work in this direction is this something that's on your radar um well i i i think that there's no reason why it can't be other than like what we're seeing from market forces

right now is that that's a very you know specific sort of um you know application i mean when we we went to start off thea i mean you know privacy and in preserving you know user freedoms was really important but the market just doesn't care i mean you know we see secret that has of course um a privacy preserving bridge there's nothing incompatible about this that is more computationally expensive um so uh the it'll be interesting to see if there are driving forces be behind you know um doing the engineering list of of adding in privacy but for right now i i think that we're you know we're really not seeing that unfortunately from users um

oftentimes i think with the like with the way we develop you know protocols for internet uh we sort of build those in and um you know bonus um and and really have to focus in on the practical applications for why it's important unfortunately what about maybe more generally zero knowledge technology because that doesn't always have to be used specifically for privacy given that we're the ck validator and i do the zk podcast got to ask that question too um yeah is there any way to incorporate zero knowledge technology or maybe other advanced cryptography like maybe threshold decryption i mean there are oh there are two things yeah um i didn't get to talk about the privacy thing just quickly okay okay wait why

don't you why don't you mention you do the privacy thing and then segue into zk tech if you want well i think they're related actually like so okay the frontier is interoperability where you have privacy in the interoperability layer um where you could actually hide traffic flows between blockchains um i think that there are probably going to be like you're going to be able to do it initially in specialized state machines so you know ibc has very agnostic about like which the how the state machines are designed on either side of the ibc transaction like you could send an ics 20 packet to a state machine that was written in rust

it has a utxo model like all kinds of completely different uh uh systems i think probably in the near future you might be able to see traffic hiding between blockchains that have like very similar and well specified state machines um that are designed to facilitate that um there are out there like sort of sketches of very zero knowledge proof heavy bridge designs um and i don't know that anyone is actually working on implementing them um but they may show up eventually where where would we find stuff like that though like what is it sort of early ibc kind of architecture is there is there

sort of a direction we could even look for that kind of stuff i remember talking about this a lot at the zk summit in san francisco okay which seems like a roughly 200 years ago 2019 in end of 2019 during the blockchain week there yeah the last time we did it in person ck summit oh man so i think there are recordings from that floating around although i don't remember anything about ziki bridges um i do know who the speakers were i'd like to yeah if you if you have any if if that does actually is sort of a call to anyone if people are finding research or if anyone knows of work like that i would love to see where that is and even if it stopped in its tracks

two years ago i think it would still be great to find all right well i think we're at time susanna i don't know if you want to jump on and i want to say thank you so much to everyone on this panel for going through the bridge panel with us during the event thanks everyone