Privacy in Cosmos Live: Bridging Panel Discussion

Transcript

cool all right so um this is the bridging panel obviously bridging is a massive topic at the moment um i'm currently on the podcast actually doing a series on bridges i've had deborah and sergey on so far although your episode comes out i think in a week and a half or something but yeah i think to start off let's introduce ourselves and i know chris for this particular uh panel i had i'm going to ask you a lot of ibc questions even though you're actually now at enoma so why don't we start with you debra yes uh hey thank you so much for having me here and i'm really honored to be among so many amazing builders and also thank you as uk validator for putting on

the conference it's been great um my name is dabra simpier i am the ceo and co-founder of althea which is a decentralized routing and meter billing platform for a distributed or multi-entity broadband networks which sort of led us to needing a bridge between stable coins and the ethereum evm ecosystems and cosmos so althea is also the kind of driving force and team behind gravity bridge so gravity bridge is a neutral decentralized bridge that's purpose built to support the cosmos ecosystems blockchains taxes

and projects very cool i'm christopher i currently work as co-founder of noma which is a occasionally ill-defined very large set of protocols for coordination privacy preserving bartering privacy preserving transactions and a whole lot of other things i worked previously as architect of the ibc protocol and i must say i grew up in oregon i had shitty internet i've never met you in person and thank you for solving a real problem hey everyone uh great to be here and thanks for the invite so i'm sergey i'm a co-founder of axler my background distributed systems cryptography uh spent a lot of time kind of designing various protocols you

know standardization of standards like bls signatures and so on and so forth and uh sometimes a faculty at the university of waterloo and uh now we're working on a secure transport layer for uh web3 with xlr very cool um chris i actually wanna as as you were doing your intro i had this question that came up so you work at a noma like now you're now co-founder of anoma is anoma in any way an interoperability project do you think of it that way um is it a bridge in a way i guess i'm not convinced that interoperability will be a separate component of projects uh okay how i would answer that question that's certainly we

want to use and contribute to standards such as ibc very cool all right so i think um to start off i think actually this speaks to this idea of bridge philosophies let's maybe start there uh each of you i mean ibc gravity bridge xlr have different philosophies potentially so i'd i'd like to explore what those are kind of what is what was the what are you setting out to do specifically with each of these i'm going to say bridges for now i know we have different ideas on what the name of these things are interoperability zones or something like that but let's just use bridges or bridge technology but yeah what's the philosophy of gravity bridge

oh good question um so uh we what's the goal i guess right and first of all i'd like to also share that you know my co-founder and cto justin kilpatrick really did a lot of the design um and and did the technical lift of the bridge so i'm here representing sort of the business aspects of it and i hope that you know folks will find that kind of interesting as well um so when we looked at designing the gravity bridge we wanted something that was going to be simple um it was going to be reliable and secure because we were looking at our end users which are other cosmos blockchains you know uh dexes and other like infrastructure in

cosmos um so with that in in mind we [Music] we sort of looked at basically um let me kind of back up a little bit here so basically looking at the user case of other other blockchains you don't really want to think about your bridge right i don't want to have to think uh about whether it's operating so we wanted to make something that number one other blockchains didn't have to think about was always going to work was very practical was gas efficient for their end users as well in fact with gravity bridge and the batching technology we're able to get

sends as cheap as 1 8 of a cost of a normal erc20 transaction and we wanted it to be able to be simple enough that we didn't have to have an upgradeable uh contract from the gravity uh sole or the ethereum contract so that makes it very secure but expandable um in that functionality so you spent a lot of time really getting those fundamentals right it's not a lot of bells and whistles and flashy things but um it just works and you don't have to think about it cool and one thing about it is like it's it's primarily focused on connecting ethereum to ibc right like that it's sort of this one too many many to one

would you say like that is that the primary goal of it yeah i think you know um we wanted to use yeah evms right we want to do things well right and then iterate on that process i think you know to chris's point earlier about you know maybe interoperability is like part of the innate future um i think that may be the case but for now we're now at a situation um where we want to do things uh you know get that user adoption it really is focused on um what works now um and what's needed now cool okay ibc if you're going to put on the ibc hat for a moment what is the philosophy of ibc what does it do what's the goal what's the goal of

it i mean i think most people here know but sure i mean i would relate the philosophy of ibc to at least for me the philosophy of uh decentralized infrastructure in general which is to allow those who are using a system to also control it of course those mechanisms aren't perfect i don't think we've succeeded yet you know validators and the users of a blockchain are pretty separate groups but maybe we've made it closer than you know one party and like you know the fed bank far away right so we want to bridge those gaps and while bridging those gaps we also uh you know communities want to interoperate as they control their own infrastructure they also want to interact with other communities while uh in some ways perhaps limiting the way that they do so

if interactions you know that they might have with other communities could lead to harm back to their community in the future so ibc just provi ibc is unopinionated about the content of those interactions but it tries to provide a framework to allow the choice of how to interact with other communities to be deferred to the user and that's and that's the thing is it's a framework it's a standard it's not a zone of its own ibc is not a token it's not it's completely non-competitive it's not you know you don't have to do anything or buy anything or be anybody or talk to anybody or adhere to any you know it's just a standard people can use it's a language it's a language it's a glue between the zones so this is just sort of nice to start to see those comparisons okay let's talk axillar

philosophy yeah it's been pretty simple from day one it was to allow any user to use any asset on any chain all right so and i think to get there you know you have to realize continue to have three core properties i think one you have to have decentralized and secure architectures that scale right and support um decentralized protocols at the bottom to you have to think about you know how do i enable what i call as like one click experiences for the users right um it's like i click my transaction goes it arrives in applications executed i don't have to think about you know bridging protocols or anything like that and i think the third one is scalability right i think our goal from day one has

been to build a secure kind of transport layer for web3 and that includes being able to connect you know millions of chains and thinking about what is the architecture that's going to look like you know is it a combination of ibc maybe other things how do we get there and two being able to do arbitrary you know information exchange so not just token transfers being able to send messages being able to exchange you know nfts and so on and so forth and so i think those three core properties security one-click experiences and arbitrary scaling is what we're focused on i feel like with a lot of the bridge projects i mean one question that people may have is like we have ibc why not just encourage everyone to enable like to have this as the standard

are there reasons that you're thinking about maybe where this either doesn't work i mean i i have a few ideas on that or that you don't even want that to be the model of the future you wouldn't want every network glued like kind of connected to every network but rather have some sort of hub yeah that's another great question um i think ibc has a lot of the idealism that blockchains really strive for right that resiliency and decentralization um but i think there could be a potential pitfall here and that we are just we could end up designing uh app blockchain or a specific blockchain to um

the need to interact with ibc um rather than designing for what's best for that blockchain um and i certainly think what's exciting is we now have you know a lot of new blockchains sort of coming online and new bridges and we have a multi-bridge future that marketplace is probably going to start to inform what our ultimate ibc protocol looks like right um but i think uh absent of that sort of competition in that building we may end up designing um a product that isn't doesn't have product market market fit i mean so

i guess just to step back i think you know my first i guess interaction and thinking about ibc in general were like in 20 uh what was it uh 2018 i would say or maybe early 2019. so we shipped the outground blockchain with my co-founder jorges and you know we're thinking about interoperability protocols right and uh you know kind of looked at cosmos ibc i mean great stuff was built and we're just thinking about how to adopt this to the outground blockchain and um you know um kind of why the model is great the practical engineering hits you pretty hard in the head uh pretty soon and like especially like for our grant i think we'll literally have to like rewrite a lot of the consensus pieces just to make it to work so um it was really hard to

you know convince anybody to do this i would say and it was really hard to you know allocate those types of resources and say well you know now we have to change like the way we built consensus for the last it was four years from the research until you know until we ship the blockchain and so that engineering kind of hit us pretty hard in the head so hard to scale across if you want to innovate on other things that being said though i do want to decouple a little bit and you know recently wrote a blog where we try to structure a little bit different layers of interoperability right and i think it's important to understand like there is the kind of the transport layer of interoperability there is a verification layer and there is a message to mantex layer right and i think it's you can stay take ibc you

could also decouple it in those layers and say who provides the transport what provides you know message verification which are light clients for the purpose of ibc and what are the packet semantics on top of it right like what is the format in which we send messages um so while i i think the verification pieces serve pretty hard to scale the lite client you know you could decouple these layers and say well message semantics for ibc could be reused across different ecosystem we can code those on top of other transport layer or verification layers while still being able to talk to one another right and so they're already decoupled i know they're decoupled i think very few people know how to actually work with that decoupling so and like i understand that so but

yeah so i think it's a um yeah so i think it's important yeah to educate people on the decoupling and what we can do with it to kind of continue making advancements faster that's actually that leads to a question i just was thinking of which is like would would it make sense to build i like to not rebuild ibc but like since it's hard for other blockchains to implement it it's mostly built to work i guess with the cosmos sdk but like could it be rethought to work with other kinds of blockchains or is that like a crazy idea uh i i think it's tragic that it hasn't happened yet okay i mean maybe it's worth distinguishing between ibc the sort of theoretical protocol architecture that has like a spec and abstraction such as like clients and ibc

the concrete implementation which is easy and inexpensive in terms of developer time to merge into your blockchain you know in a few weeks and the former has a kind of extensibility that the latter doesn't yet have in practice yeah so there are great implementations of ibc available in the cosmos sdk and go and in rust but you know for other blockchains with other light clients other signature schemes even if it's sort of possible in principle to integrate that into the ibc model uh if if if it's not yet cheap enough practically then yeah people may not do it um the boundary of ibc is not a fixed thing so ibc is like just a sort of set of abstractions around interoperability just as like tcp is a set of abstractions around sending packets and

you can come up with uh say new light client algorithms which would expose different uh consensus algorithms to the ibc ecosystem or you can come up with you know i would say like gravity bridge not the instance uh but perhaps the protocol could become part of ibc you know it doesn't the the we can separate here the concern of what should the specific instantiation be now which is a very pragmatic one uh not to devaluate at all but that that has to be made on i think on the terms of like what it what are the conditions at the moment who can work on this who wants to use it like that has to be made on the basis of practical considerations whereas we can also leave the path open for you know the topology of real commerce on the network with which the

security architecture in order to be secure has to reflect we can leave that topology open to future change by building the protocols as a kind of stack which is independent of the specific like tokens and the specific instantiations yeah just 100 agree with that and i think that the market is really going to drive you know how this this um you know moves and changes i also think too that we we all still have this fundamental like kind of tooling and node infrastructure issue that sort of is where a lot of these pain points to evolution of both ibc and bridges is you know kind of hurting right now um one of my questions was about like could bridges become this sort of centralized point of failure but before i go into that it's like the ibc world the way that it was

originally presented was very much like this mesh or this net is that like now that we're starting to see it in action are there kind of like still hub and spoke kind of entities forming even with ibc like is that is it a perfect mesh basically or not i mean so yeah i have like a lot of thoughts on this but uh i do think you're gonna see you know hubs and i think you're gonna see spokes right and i think it's i think it's sort of fundamental for the blockchain ecosystem and here's the reason um you know whenever you're talking about like peer-to-peer connectivity right like look at two extremes okay extreme number one everybody's connected directly to

each other great extreme what is what is the result the result is like and you know in the order of n squared connections impossible to manage right like you know nobody's going to run so many relays nobody's going to maintain these many connections that cannot work right the alternative extreme is that you have you know one hub and everybody talks to that hub again what is that hub going to have a million connections probably not right um you know so you're gonna end up like in an architecture where you know there are some hubs there are some peer-to-peer connections how did the internet shape up right it's sort of you know you're going through multiple hubs on average you're taking kind of a 10 to 20 hubs to send the packet the challenge with that on the blockchain space is that every time you take an extra hop you take an extra

security assumptions right so you're trusting another validator set maybe even trusted another protocol and like those continue amplifying and amplifying and so you end up with pretty much nothing if your packet has to go through you know 20 security assumptions and kind of hubs help you uh minimize the the trust assumptions as you're kind of moving the packets from one connection to another i think it's kind of interesting though i think it's a bit more nuanced on that because many of the validators run the relay infrastructure right so we were talking earlier about like interchange security um and liquid staking and then also the sort of problematic um centralization of like white boxing and white labeling validator sets right so perhaps it doesn't really look like a hub and spoke model from the outside but

really we you know we are um you know doing that underneath the hood right so i think there's there's other sort of um you know perhaps more nuanced more subtle ways that centralization and aggregation happens across at least the cosmos ecosystem yeah i would add to that that part of the design of ibc which hasn't really come into practice yet uh is uh fault tolerance for byzantine behavior not in the sense of byzantine validators but in the sense of byzantine chains within the ecosystem and we haven't seen this yet because we operate in this nice world where we're all friends and we go to conferences and talk to each other you know people are rational but they're also kind of nice and they don't want to be rude to the guy who are they having drinks with

we're not yet in brutal competition um nor are we in like cases where there are i mean most of the usage of block change is imaginary financial speculation let's be honest we're not in cases where we're dealing with real world power structures who will try to subvert many of these mechanisms for their own specific ends and i think continuing to design protocols that are tolerant in this way is extremely important even though we're not going to see that realize for a long time say you know it's not clear proof of stake will work in the long term in the long term considering like the practical economics of validators and like how delegators make decisions are lots of areas in the design space that need to be explored before we can see these things in practice um

i had a question and i'm blanking a little on what it was what was it well you're thinking that i could actually uh continue the conversation i i think that it it is interesting that you you bring up you know hey we're all friends we all go conferences one of the things that's really interesting to me about cosmos is like the ecosystems are the same the validator sets are the same the communities are the same you know we all cross-pollinate a little bit right so what sort of happens when we cross-pollinate with our security right we start to do that with the you know liquidity there was questions about what happens with those derivatives right like how does that actually affect um you know i would be curious your thoughts about that in terms of like bridging or interoperable protocols too because um you know maybe these communities

start merging more and more together right staking derivatives are terrifying they keep me up at night i mean in some sense it's easy to turn anything into a fungible asset yet fungibility is also the very property which like uh say validators are secure only because they are not fungible right if votes are a fungible commodity that you can buy then you you know you no longer have any kind of guarantee provided by this decentralized and i think we're already seeing that with like things like bribe dow and you know that's already you know coming to the ecosystem where we have to decide where we what we feel about it sorry for derailing no prob thank you because it gave me a second to find my question which had been actually this original idea of the point of failure our

our like bridging zone so i think ibc wouldn't necessarily fall into this but like a hub of ibc connections could or these bridges or these interoperability entities are they i mean we have examples of hacks that have happened oddly except for the most recent i guess oddly they either get bailed out or they the funds get given back it's sort of still friendly um but yeah what what about like are the bridging areas are they going to become the points of attack are they a point of failure for these larger networks of blockchains um i mean yes is the answer but you know i think in some sense it's like

no different than um kind of just building in web3 right or d5 i mean i always give an example like okay like early d5 we saw hacks because people were shipping you know crappy code not audited didn't know how to design things securely and so on and so forth and we kind of went through a couple years of iteration until we see protocols now that you know even sometimes they still find um you know find find vulnerabilities so you know interoperability is a new space so i think we saw a lot of ad hoc solutions being rolled out which hopefully will get replaced over the coming years um so i do think we can make it you know better and i do think we can make it secure i mean that being said i think also i mean we've been exploring some ways you can actually compose

security across different um across different protocols or potential across different paths right so for instance you can imagine that like i'm gonna i'm a protocol you know on ethereum or in cosmos and i actually would check that like two paths have verified my traffic and those are like independent paths and only then i execute a message and only then i sort of authorize it so you can actually do quite interesting things to compose make security better remove some of those centralization kind of problems that you talked about you do have to have very kind of strong engineering on the back end and the you know rigorous audits and things like that cool yeah i um i think a lot of these hacks are

somewhat mischaracterized right so what's happening here is the trade-off between security and usability and ergonomics speed um things like that right and a lot of the reason why the bridges the bridge tax get paid back is because really those those bridges aren't necessarily acting as an interoperable neutral infrastructure layer they're really operating like it with axia was you know it was an axi bridge right they're operating to serve some other kind of thing so they make the trade-off um for a more efficient centralized design which you know then leads to the very problematic design challenges um so i think that's impo that's why it's important that

that neutrality and the interoperability of that infrastructure layer itself is really important right but we don't make those trade-offs um in terms of efficiency uh and i think as the tooling and and efficiency like with gravity you know um right now it's even a profitable and sustainable bridge you know we're able to get gas costs down as these bridges become better then people will be less likely to make those choices at least that's what we hope but i think to a lot of end users a lot of these security properties are just not you know disclosed right so for them it just all seems like well or all bridge is bad yeah um you know in many cases this isn't even really a decentralized bridge it's

you know a three-person multi-seg or something yeah i mean i would say growth incentives are dangerous you can only optimize for one variable at once if you optimize for growth of your system and sacrifice security trade-offs whenever those decisions come around then eventually it will fail uh you know it's not the good news is that i mean it's it's unfortunate battle testing in the sense of do consumers who are using these systems understand the security models no are they communicated to honestly no or their intensive organizational efforts being put into telling users like how precisely the system could fail and enumerating the ways in a way that's understandable when doing so would be contrary to the financial interests of the organization's operating web apps no

i mean but at least we're battle testing it and there is you know the question is whether that feedback will translate into kind of a collective consciousness of which sorts of system designs have which properties in operation or whether it will be sort of warped and never really result in the right bridging protocol such as ibc being adopted uh really my bias there i would say one more thing and i promise i'll shut up uh i don't know currently we get away with bridge designs that are basically content blind so as in the security of a bridge you know we have some formula we have some like uh decentralized validators that controlling the bridge and all transactions across that bridge are treated as the same both in the

sense of like we don't subject them to different confirmation times or different uh additional authentication through separate paths and in the sense that to the user we don't like the wallet doesn't wait for longer we're not we're not we're not changing uh the like dynamics of what we treat as finalized or secure based on the content i think that is it's nice and it's convenient but if we look at real world systems like banks of course they authenticate transactions based on content if suddenly i wire everything in my bank account to uh you know somewhere in in southern africa my bank will go what on earth are you doing um of course finding ways to do this that are also permissionless and uh privacy is hard yeah it's very hard um but uh uh there are like users could write

their own sort of configuration for what to allow on their account if we move towards a more programmable account model well and i think in that model becomes very interesting um the community governance aspects right you know you have something that would happen with juno right the social consensus um would they be perhaps censoring those transactions the community's saying no we don't want this or not we do and maybe that's a good thing but i do think that that it's um a bit uh it could be optimistic or dystopian yeah transparent blockchains are a terrible idea stop using them there will be authoritarian governments in the west in like they're already authoritarian it's going to get worse do you want your financial history now to be visible in 10 years are you sure you can never undo it

sorry that's about to lead me to the next thing which is privacy but go go for it but yeah no just kind of a quick little ad right like i think to your point though like should bridges like you know treat transactions serve differently and things like that i i don't think like at least my philosophy like british should not treat transactions differently but you can get that security at the application layer at the end at the entrance and exits essentially yeah right because i think if bridges start doing that i think you're going to get lead into you know pretty bad kind of complicated designs where you actually have to manage this complicated infrastructure layer but you can do all of this at the application layer yeah so i want to we don't have too much time i want to open up to questions but first i want to

just bring up the topic of today which is privacy and bridges it's a topic i feel like i'm kind of constantly trying to like put into the conversation but it's clearly not like a bridge topic privacy like i don't know of any bridges who are like thinking first and foremost about privacy that's why i was asking if a noma considers itself sort of a bridge if so you'd be the one that i that i could point to but yeah how how do we think about bridging and privacy is it always going to be an afterthought so i think um you know no matter how much i love privacy and like you know i spend my time in cryptography i think privacy is always comes after you get some functionality i think we're in a phase where you know we're still kind of

setting up this core connectivity pipes and like dealing with attack vectors so um you know i think that's why people haven't thought about privacy too much yet i mean that being said i think you know we talked about it last week right and i'm super excited to kind of compose interoperability with privacy preserving like hubs or networks right where you can kind of send packets uh do some privacy preserving operations within it and take your messages or assets out somewhere else so i think that would be the first use case where we'll see kind of privacy being composed with um other ecosystems which i think is going to be really powerful i like that distinction too because i think often when we think of bridges we're thinking about token transfer so moving tokens from one to another but when you start to think

about bridging messages then you can actually you're doing something in the private zone but it's not just that you're putting tokens in the private zone that's very different you can move some part of computation or state do some stuff on it get the result back and without having to like bake into privacy into you know your layer one from day one so you can talk to nim right or some other chain to kind of get some of those properties and i think one of the challenges always with the bridging idea is that the way we've been thinking about it is you'd have maybe a zone or a chain where you'd have maybe a shielded private part but in order to actually interact with the bridge they all the sudden unshield or de-cloak as i've been trying to push in our last episode uh start let's put a star trek reference in

there but they have to basically reveal themselves before actually moving over the bridge and this is where the privacy is often lost and i think this example of using the message passing part of the bridge is kind of a cool thing to think about i don't know if has it been mapped out is this something that any of you know research is being done on what that would actually look like what could it enable privacy on message passing and bridges no it's more like being able to do message passaging into private networks and doing something in there we're starting to do this with a couple of partners um yeah with like manta network and a few others so i think it's early days but yeah i think we can we can map it out

yeah and i know henry from penumbra is here somewhere so i i'd like to hear your thoughts on that at some point yeah um i wanted to add one point just earlier to on the topic of general like privacy and bridges i think there's an intersection here that isn't discussed very much which is the privacy has big implications for bridge security because many of the if you like model the attacker of the bridge they have some in order to determine like what to attack how to attack they need to be able to glean information about what is going on and generally especially they need to be able to glean information about the content of transactions on the bridge like is it valuable to go attack this bridge as there are a lot of you know funds there or transactions i could thwart or something like this and if all

the transactions are private that's much harder so privacy can have benefits of course it also makes it harder to see like is there something going wrong so there are complex trade-offs on the second bit i would say i mean privacy in a like complex distributed system such as you know the ibc ecosystem taken as a whole is in the sense that where how users are using it interacting with multiple chains going through multiple change privacy is going to be as weak as the weakest link the weakest link will be bridges if the bridges are always enforcing de-cloak on one side cloak on the other we need private bridges we needed to be standardized um we at inoma let me show one sec we'll help try to help and hopefully you know noma penumbra you know anyone who wants to basically can adopt a kind of ibc

shield of transactions awesome i think my my i also think this is really fascinating and i think over the next few years we'll definitely see this evolution but i think one of the reasons why we haven't seen more progress on this right now is just some of the like the node infrastructure issues we have to you know share so much information right now um that you know the encryption overhead is even harder higher than you would if we could pare down and we had better tooling in the cosmos sda infrastructure so um you know and this is even between when ibc first started coming out and the failure rate versus where we're at now i think is a really a testament to to everyone there but unless we number one um you know sort of work on that pain point and number two find ways

to incentivize working on that pain point so it makes sense that you know you know relayers uh can run a light enough infrastructure that they're able to make money and um and then then i think we'll see privacy follow that but we have this kind of big you know work to do that's kind of boring and um right now isn't well incentivized that's core infrastructure all right i think i want to open the floor to questions if there are some ah there we go first of all thanks for the panel like it was really interesting and i have few questions uh one it's about

token fungibility so what is your answer to like importing different versions of the same token depending on which bridge you are using and another answer question i have it's uh about bridge monetization uh like as i guess we are approaching into a multi-bridge ecosystem then how to guarantee the development and the continuous like uh management from a technical perspective of bridges and uh that's right and then like what what is your opinion on on peggy that is the bridge that shifting has been running for one year uh about ethereum and cause you have three questions that's it first one

is fragmentation of liquidity or like exact like the same this is i think just to be clear it was like if you have multiple uh versions of the same kind of bridge token on one network is that uh yeah exactly it's uh like how to avoid to have the ethereum version of osmosis against the ethereum version of another bridge and so getting into the token fungibility groups and make sure that we are all working with the same version so let's start with that one sort of this yeah i think it's a great question you know it's interesting because i think you know maybe last year or so before i think there was like sort of the thought that maybe there could be like one bridge would be the standard and you

know obviously that's not the future we have a lot of great bridge teams and um so different assets is is the reality um i think you know certain like fungibility you know asif chain has actually really led the conversation on that um which is unfortunately not really gotten a lot of traction but i think there's some also some interesting ideas about pooling the assets too um that you know with liquid syncing or superfluid staking that could be also somewhat interesting so um you know we're going to have to we are going to have to face this reality very soon yeah i mean i i think for the business like can be solved i think if you decouple again like application logic

from transport logic effective application logic you can you know you can have things like you know authorized transactions from like this bridge or like this path and like only then they can be minted so um i think like you you need to decouple the reason we're dealing with it is because token transfer has been baked into the bridges which is horrible so i think you have to like you know separate logic a little bit and deal with it at the application layer um uh asset fungibility uh can be solved at the protocol layer it just hasn't happened yet you need to face commit between the three chains involved then you can get rid of the diamond problem because uh all of them agree that it won't be double spent and then you can treat them as fungible and it's safe but it requires consensus protocol changes and

cough public goods infrastructure funding cough those don't easily happen because we're all busy launching more tokens on different blockchains we should all just work in one organization and it should build one blockchain and we should be done and it should work you know one protocol to rule them all one protocol one protocol many different blockchains you know but one protocol or one like integrated set of protocols all right question number two is about maintenance and tokens on the bridges themselves yeah the monetization of bridges in order to make sure that the bridge is sustainable from a funding perspective so gravity bridge is profitable right now um we really designed that so that the the token holders could get any sort of fees that they would through

community governance pass in the native tokens that come through so that makes it really um you know aligned i think way of interoperating with the other blockchains who are core customers um and the relayers relay profitable batched transactions so you can send transactions instantly or you can choose to send transactions uh you know when they're batched and then they're relayed when they're profitable so right now we're seeing um you know folks that want to spend less gas um you know and get into a box transaction they're going to be you know an hour to like four hours somewhere in there and then instant transactions go across but right now it's working it's profitable

and it seems to be um you know able to be scaled in that same way yeah i mean i think monetization and long-term sustainability is no different from like layer ones or other infrastructure projects you know you you charge fees for processing requests and you know you just have to make sure you you know cover all the gas costs on the on the chains you're bridging so you just have to kind of be a little bit careful there but um i think it's it it's it's not too hard in some sense you actually have a lot more flexibility because you're dealing with you know multiple tokens and multiple networks so you can charge a little bit more and the source you can charge a little bit less and things like that so you have a lot of parameters you can tune in i want to see if anyone else has a

question because we did answer two of yours cool maybe it's kind of too new but with interchange accounts launching like what kind what kind of opportunities does that have for like executing transactions in a private way on blockchains other than the blockchain you're on and then would if you wanted to do something truly private would you have to be in like a fully private zone and you could only then interact with other private zones or is there actually scope to have privacy from like a non-private zone to a private zone something like that i don't know if anyone knows but yeah i didn't get this one

i'm just i'm just wondering like what kind of opportunities there are for like um executing actions privately through interchange accounts but whether there would be limitations on as you're saying like privacy is dictated by the weakest link like would you only really be relevant if you're just dealing with fully private zones and such or could actually be an opportunity to have private actions executed from like a less private zone or something i mean i think this is yeah a little bit back to the kind of conversation we had with you know general message passing and i think entertain accounts is sort of in that direction is that you can yeah pass an arbitrary message to ask you know a different zone to execute like

computation on your behalf right so as long as like you know you have zones that expose this functionality you can um you know you can send them information there you can ask them to do interesting things in a in a privacy-preserving way so yeah i think of interchain accounts as like a step towards that did you have a question um is this is this on what yeah we can hear you um yeah i mean i don't know if that question was necessarily specific to bridges maybe more of an ibc question but um yeah i wanted to to ask um there

it seems like there's a like a time preference um that's starting to that we're starting to see in message passing so um the gravity gravity chain for instance does batching on like a daily basis or something like that and i think axler has some options where you do like low time preference high time preference how do you see the the kind of classes of user and and message passing evolving and and how how do you imagine kind of servicing those users that's interesting different timings so

to hearken back to an earlier presentations and name earlier talked about a mixnet right and if you have in this hypothetical world which we don't live in yet but where we have private crosston interchain accounts and now all the transactions are in private then we have the like statistical attack problem because you can see if you see which messages are going between which blockchains even if they're encrypted you can perform timing attacks so batching helps with this you want to batch private transactions or private actions in that way for the same reason that you want to batch packets in a mixnet um and i would say yeah i mean they're like a lot of interlacing dimensions i guess you know batching can often save on costs but it can also provide additional privacy and in the long run that might even be the dominant consideration i think the

question also has to do though with like this preferential treatment for like some users going faster right we're kind of like treating like we're putting everything right now under the umbrella bridging but like what we're starting to see is like actually a segmentation of the market into okay i'm an mev trader and i need like fast execution and maybe maybe so fast that i want to use a centralized bridge rather than a decentralized one or i'm a privacy preserving user that has like a low time preference and i can wait like a month for something to come out of the bridge and be fully anonymized um there's oracle messages or nfts

versus fungible messages like these have these are also kind of segmentation of the market and and so yeah i'm i'm interested in your views and kind of like how this differentiation in the market is is going to play out yeah i think i think it's a great question and i think you know gravity bridge really sort of uh came from the uh onboarding of like more users and that aren't currently in the crypto ecosystem so that's where a lot of the thought process around batching and making cheap transactions and exposing those choices to the end user i mean i think is ultimately um you know the the goal of what we need to be able to do the crypto market is still you know small right and and we're going to need

to be able to support institutional capital support a larger set of you know real world users um and so uh and and um you know we need to build for that sort of user choice yeah i mean i mean i think it's some in some sense like the problem is again like no different than like problems on layer one infrastructures themselves right because uh you know gas fees sort of dominate in some sense uh performance and so you know depending on how much user pays like they'll get a certain process in time and i think kind of bridging being infrastructure um inherently suffers from the same problem i mean i think privacy here can actually help right and uh um you know with

you know either batching or just privacy preserve in ways that you know you can upfront run users because you don't see what the transactions are um as they're moving through the bridge so uh but yeah i think uh it it's a similar problem that i think just expands beyond bridges yeah i would say i mean how to think topologically about sort of user prioritization from a protocol design perspective depends on what we want the system to be able to provide as product level guarantees to users and one thing we might want like a financial system to be able to provide or sort of economic system to be able to provide is quality of service for individuals taking actions in the physical world that are predictable in advance i want to be able to buy coffee

i want to be able to pay my parents far away i do this you know roughly at this frequency they're like real world things happening um in order to provide that i think we probably just cannot get around a hard problem of identity uh like you want if you want to provide most you know with what most people do with their credit cards are sort of interacting with economic systems it's a few times a day or something in a predictable way i think it's critical for ux reasons to be able to provide predictable low costs and guaranteed like low latency for these uh specific interactions to users they can plan their lives out in advance and we probably won't get that without identity one thing i wanted you mentioned qos right so this is like very much that intersects between internet though too so right now the carriers

decide like the qos right so i guess my point earlier was that i 100 agree with you um but i think it does have to come back to like let's make deliberate choices right now that expose this qos to users so they have that choice cool all right i want to say thank you to the panelists of the bridge panel i know we've gone a little over but uh yeah thank you so much thank you thank you so much i think we're about nine minutes late my apologies we got into it