IBC EVERYWHERE with Bo Du of Polymer Labs

Transcript

we're live my guest today is Bo do he's co-founder at polymer Labs polymer is advancing web 3 and droppability by building a universal and modular IBC router that expands the IBC Network super exciting in today's conversation we'll discuss why it's hard to expand IBC outside of Cosmos SDK chains and it will also dive deep into IVC and how it works we'll talk about optimistic IBC zkibc uh their new ZK friendly tenement consensus engine I guess it's not that new they released it a couple of birthday announced a couple months ago uh and uh integrating polymer with the modular stack I'm also dying to find out why he thinks other interoperability

Solutions are not protocols before we get started make sure to hit like button hit notification Bell And subscribe to get notified when I go live every week and remember that know what we discussed here on the interop is investment advice and if you like what we're doing on this channel please consider sticking with us we're valuing on the fmos Quicksilver osmosis and Juno just look for interop in the active set and I hope you've booked your flights to Paris for the summer oh I know you have because nevertheless Summit is happening on July 24th and 25th it's a two-day conference with technical talks about Cosmos IBC the inner chain no panels no suits just Tech talks and a lot of fun tickets are still on sale and you can get those at nebler.builders and if

you're coming to Nether Summit you should also register for never hack day that's happening on the 23rd it'll be technical workshops you can find all the way the details on the website my guest Bodo is coming up next right here on the interop thank you hi Bo how's it going not bad how about yourself great thanks for joining me here on the interop I've been wanting to get you guys on the show for a long time and

Peter was always like yeah it's not it's not the right time it's not the right time but I'm glad today is the right time because uh yeah polymer is super cool and you I mean I'm sure you know this but so many teams that I talk to tell me that they're integrating with polymer and they're looking forward to polymer and polymer is going to solve so many problems and so uh I wanted to get you on the show to talk about uh IVC hopefully getting a better understanding of IBC if we talked about igc on this channel so many times but just getting a deep technical understanding of it how it works and why it's hard to integrate IBC without the chains uh that you know don't support common bft and um and so much more so yeah first how did you get

interested in interoperability as a as a problem that you wanted to work on uh I would say it started with my time working part-time in D5 so I spent some time Moonlighting um on the side on a number of ethereum D5 protocols and this is kind of at the tail end of D5 summer you had an expansion to different chains like BSE and so on and you had some of these early like interoperability products like a multi-chain uh Slash any Swap and there's also like other existing Solutions uh like decentralized custodians or somewhat decentralized custodians like Ren uh and at the time we were trying to

expandable because yeah I was uh um we were actually collaborating with them as someone in the early days uh like they actually had similar ideas to uh what axelr is doing now uh like they had like the ren VM they like actually was like you know AVM although it's not really actual RCM it's uh cosmolism but Ren you know had some of these plans and some of these ideas and as I was building on the D5 side I was like oh look maybe we can explore like how we can expand cross-chain and then through that expansion it was kind of like apparent to us like if you wanted to build something cross-chain you had to build like another blockchain because there was no way to like really uh seamlessly interrupt there was no like uh General interoperability solution

across all these different ecosystems at that time which makes sense because you know it was like a heavily concentrated on ethereum a lot of the D5 and I slowly started expanding out the early projects like door chain uh try to tackle this um but then when we started to build I guess some of the early versions of of what we wanted to do on the interoperability side we kind of realized that uh the solution that we're building was like very similar uh to to like IBC so as we were trying to solve some of the questions of you know if I have two smart contracts on two different chains if I want to negotiate uh versioning across them I want to like handle upgrade ability uh if I want to have like authenticated communication

pads as you like go down the laundry list the features you end up in like a very similar place to IBC so like through this building process and also through this like Discovery process we hard like focused on we should just build with IBC figure out how to extend this protocol to all these different chains very cool yeah I mean and and very needed because I think for a lot of folks in the cosmos space that have been following you know Cosmos since the beginning IBC has always at least for me been this this really impressive uh standard that we all hoped would spread to other chains outside of The Interchange ecosystem and it really

feels like that's starting to happen you know there are teams that I mean obviously you guys are a big part of that uh helping that work uh happen there are teams that are building IBC you know connections to uh Avalanche to Solana to the move ecosystem to to near Etc and uh it really feels like the IBC pill is spreading across the boundaries of Cosmos or The Interchange is that something you're also seeing happening like when speaking with teens outside of Cosmos do they do they have knowledge about IBC are they familiar with it are they bullish on it or are other interoperability Solutions uh favored there

yes I see that a lot of folks that are very interested in IBC uh as you mentioned there are a number of teams building with it and extending it to different ecosystems but I to play devil's advocate here I also see there's a lot of folks that you know it's difficult to integrate natively so there's a lot of folks that you know maybe have tried to do it um maybe they have like different opinions on like why um you know we should have something simpler I've seen the argument for like oh connections channels packets that's you know it's too complicated like why don't we just have like a simple get posting um and I think what a lot of people Miss is there's layers to the stack and I think what's Optimist is the the concept

of these layers and and how they fit into each other since if you think about the problem from like let's make something super simple like get post or just I'm just gonna send some bytes from one chain to the next it limits what you can build since essentially what you're describing is an application layer protocol and not a transport layer protocol and we'll get into that more uh to the rest of this podcast yeah no and then and I think that's that's accurate I think realizing that there's more than just sending bytes from one chain to the other I mean you you have to uh take into account of course the transport layer the the the um that sort of adversarial uh space that exists there right in the transport

layer between different uh chains and then the state layer I mean State needs to update between uh on two different uh State machines and that needs to happen in lockstep it needs to happen uh accurately right like if assets are minted on one chain well they have to be destroyed on the other and that that has to happen in a certain sequence and uh with with some degree of uh of certainty and so all these things taken into consideration make interest probability so difficult that's why interoperability and crypto has been so difficult so let's let's dive into IBC a little bit and I'd like to maybe start by describing let's take a simple example let's say

the example that a lot of people are probably familiar with right they listen to this podcast is moving tokens from chain a to chain B let's take you know Adam like the cosmos Zone we're moving atom to osmosis when when you open Kepler and you initiate a an IBC transaction from Cosmos to osmosis what's happening behind the scenes like from the atom Zone to the cosmos Zone how are those how's that information being transferred and how do you magically end up with like Adam on your on your Capital wallet over on osmosis so I'm going to gloss over some of the the transport layer details and focus on what's happening at the application

layer since token transfer or ics20 is an application standard it's an example of what can be built on the IBC transport standard but I would say that like it's not it doesn't it can be built on any transport standard but um on the IBC transport in particular you're able to kind of like agree on some semantics here so for when someone transfers some tokens they're essentially escrowing those original tokens so it's not like the tokens get burned and I think a lot of people have this uh misconception that these tokens are burned and invented on some other chain they're actually escrowed by what's known as like a module owned account

this is essentially controlled by the change consensus since you have some chain it has some consensus you're able to have like a chain owned account it's not owned by a private key it's owned by a specific SDK module on on that chain when these tokens are then transferred over you mint a uh essentially you could think of it as a wrapped asset because you're you're tracking the denomination and what's in the denomination is you've taken the token identifier which may be some let's just say it's like token uh like atom and then you're adding the the channel path like slash Channel ID let's say you transferred over a Channel Zero so it would be Channel Zero uh and

that's what you get on on the chain that you transfer to this this information is relative to source so from the starting from the original chain it matters which uh Channel you've gone over because all this channel information is is only uh only maps to change based on The View From the Source chain of all the all the additional change there's no like Global identifier saying that you transfer this token to uh like Juno or or osmosis there's no like Global osmosis or Juno identifier it's all relative so every single chain has a relative view of every other chain this is a this is a very difficult concept for most users to to grasp um they just assume that there's probably like oh there's like

this Global like DNS thing where everyone like knows which chain your tokens on yeah but so so just to stop on that point for a second so what you're saying is that chains on know the identifiers of the chains that they're connected to but beyond that they don't have they don't so for example when moving atom to osmosis we're using a channel that channel has an identifier now when moving those Atom from osmosis then to Juno that's a different identifier different Channel Adam has no idea that that channel exists it only knows the channels that it's connected to and so it's yeah think of it kind of like a hub and spoke right so you get The Hub and

then there's all these folks that go out and that's that's the only thing they know about they don't know about anything else beyond that yes yes that's correct and the channel thing is intentional so I think there's a lot of people uh complaining about the the ux the ux can be improved the security ux forms the basis for why they went down this the design path in the first place because the thinking is that right now every single Connection in the cosmos is like roughly the same they use like you know tournament like client consensus um the channels are to the specific chain you have a certain level of security when you have these modular security print Primitives that are being built in various ecosystems and you see a lot of interop solutions training towards modular security

you get a situation where potentially the channel the security of a channel is not one-to-one anymore so even if you're connected to the same chain you could have different types of connections for that chain and now like the non-fungibility aspect of the token becomes a feature um versus like a bug because if one of these connections attack you maybe don't want to expose the the risk of that particular State Bridge uh to these these other these other tokens that were minted on a more secure uh more secure Channel right so this is the issue that we've talked about here on the show before which which is this this fungibility aspect if you if you let's come back to this example the cosmos Hub to osmosis

did you know now if you were to move back if you remove those atoms from Juno back to back to Cosmos those are not native atoms anymore those are now Juno atoms they that you've piped through osmosis that are arriving on your uh on on on the uh on the cosmos Zone if you want to get native atoms again you've got to wind those transactions back in order to get your native atom again and this is the um uh this is one of the mod so so strange love is working on a module I believe with a Noble Team in order to always just be one step away essentially from uh from the chain the original

chain of departure such that we don't run into this issue how big of an issue is this though I mean how how often do tokens end up like on another chain like on a chain where they're they're not fungible with the original token my understanding is this happens quite often since like from if I'm a regular user and I don't like uh I'm not a like an infrastructure developer um I'm thinking that like if I have some token like let's ask some Adam if regardless of like where I transferred from if I'm transferring to a specific chain regardless of the like the denomination path that I'm on even if I Traverse already like four different chains and these are different paths I'm

expecting the same token so like my understanding is that most users just logically speaking they're like I have this atom token if I transfer to Juno it should be fungible with all the other atom that I've transferred to Juno why isn't it fungible I think that's the that's the question that you're opposing yeah yeah okay so once those tokens arrive on the destination chain so I think this was an important thing that I learned here is that they're they're not they're not burned on the originating chain they're escrow so they're locked yes and then what you end up with on the on the uh destination chain is a wrapped essentially what is a wrapped asset that represents uh the the tokens that are escrow on the

destination chain and so there's an agreement between these chains that well you know Cosmos validators are not going to relinquish those tokens again like on the cosmos chain and um and and then we would end up sort of like with two two um two positive tokens on on two different chains um is there a mechanism that prevents that that prevents Rogue like a rogue validator or maybe like a rogue voucher set on the originating chain to uh on escrow those tokens yeah if the chain gets uh taken over if there's a if there's an attack an economic attack on a chain somewhere in

the middle of the path the the security of the token becomes a minimum of the security of one of the networks in that path which is why like yeah the non-fungibility thing was a was a design choice because like if you have a token that was like transferred over let's say like five different chains the minimum the security across that path versus a direct connection is is very different hmm okay yeah we'll get into that a little bit more later I think when we're talking about about security so what what uh kind of considerations so in the context of two Cosmos chains I think it's pretty clear how that works and I think a lot of people are familiar with that and it works because Cosmos chains are able to verify they have like

clients that are able to verify the state of each other and also because they have the same consensus mechanism what considerations must one take into account when implementing IBC outside of Cosmos so with you know any other chain that's not a cosmos SDK you know Comet PFT chain what what considerations must be made in order to well a determine whether or not IBC will work out of the box and uh and be you know potentially implementing IVC in like some other way so there's a few layers that IVC protocol you have the application layer which we went over one example just now with ics20 or token transfer you have

the transport layer which is the IVC core specifications there's like the concept of a connection which is a conversation between two chains Channel which is a conversation between two smart contracts or modules and it is a concept of a packet which is just some data that you want to send and then there's a concept of the state layer or how state is bridged and I think when most people like talk about bridges that's all they think about they just they just think about like how is state from uh one Chain Bridge to another so like when someone refers to a canonical Bridge or like a roll-up bridge that bridge is bridging state like how the packets are encoded what the messaging semantics are that's a transport layer concern most of these Bridges actually don't really have a

flushed out transfer layer standard so you have to implement all these these three things these three layers on the chain that you're integrating with okay got it um and so specifically when it comes to the state layer because I think the state layer is where we run into the most complexity when it comes to uh having IBC be compatible across you know chains that are outside of the cosmos ecosystem what is it about different state layers I.E consensus engines that

make it difficult to for example Implement IBC between osmosis and Main net ethereum I actually have a different opinion my opinion kind of goes against the grain here it's uh I I think that the the transport layer is actually what's uh annoying to implement since at the at the state layer you can you know with like a modular security model you can make certain trade-offs like let's say you verifying consensus is too expensive well why don't we like shove a relayer in a te and like now you can have a connection it's not at the same level of the security you know you're making some trade-offs here but you can get connected you can bring state from a chain to another chain

um or we're using some sort of like Guardian set or or something um the the transport layer is tricky because when you want to integrate it natively you're essentially exposing the internal implementation details of that particular chain with the rest of the network and I think that's that's not the the right model to go down and what I mean by that is the transport standard is a specification around how do you make sense of the state that you just bridged so you you bridged from State some like uh state route or with other transfer side I call it like a transport route you bridge some like commitment how do you make sense of the commitment like what what are all the smart contracts talking to each other um what what about the type of

connection used can you describe that as well and then also the data being sent over sent over uh these two changes as well the issue is that I think we need to kind of separate the interoperability stack away from the stack of a particular chain itself so my my long-term opinion is that I don't think IBC should exist as uh SDK module so right now in like the even in the cosmo stack it exists above tenement so like there's tenement there's Cosmos SDK there's ABCI at SDK leader obviously is a module and I think it needs to kind of range from being a module to being a first class infrastructure primitive where IBC sits

next to tournament tournament goes over ABCI to some SDK and then IVC should go over virtual IVC or some sort of interface where it can talk to an SDK that's integrating it or a chain that's integrating it whatever that may be and these two things should be two distinctive uh too distinctive Primitives okay so in the case of in the case of uh like a transfer between say Cosmos and the cosmos Hub and in ethereum mainnet chain uh the the issue is making sense of the state that it's receiving so a cosmos Hub validator unless it is uh unless it's

verifying the entire state of ethereum through some State verification menu like a like client or something like that it wouldn't be able to know exactly what it's receiving and also whether it's been settled right like whether it's finalized yeah so if if we're you know going back to I guess the the state layer so if we want to bring state from ethereum over to the to the cosmos uh there's obviously many ways you can do this if you but if you want to verify ethereum consensus he went into the issue of ethereum does not have single slot finality as you mentioned you have to wait two

justifications of an ethereum block before it's considered economically final the finalization is an overlay on top of the block production algorithm there's an intentional trade-off that they made for for liveness and also um uh safety on the client side at polymer we have this internal Innovation so we have the concept of a native like client so the native like client represents ethereum consensus it tracks all the state Forks of ethereum so it'll track the finalized uh the finalized branch which is the doubly Justified Branch but also beneath the finalization period it will track all the existing Forks that are happening and what we overlay on top will be

present to the rest of the the cosmos network is you can create a virtual like client which is a obviously like IBC compatible like client it has single slot finality in quotations meaning that it is implementing a four Choice rule over ethereum consensus over the native lifeline so this overlay makes sense of a chain that doesn't have single slot finality if you want only finalized block you would create a virtual like client over the doubly Justified for Choice rule which is a economically final ethereum View if you want lower latency you can trade off between security and latency here you can say well I want to only want to wait uh eight blocks well at eight blocks you know you may give me your

doubt but we can apply a full Choice Rule and choose a fork for you right now we're using aggregated view because it's hard to kind of determine a canonical Fork here but essentially able to establish like different views into ethereum State at different levels of security so now you can have let's say multiple different connections from uh ethereum to some other Cosmos chain and each of these connections can be built with a different security model okay interesting well let's talk about polymer I want to get into polymer a little bit and understanding like where it sits in the stack so we we all know I guess we all kind of understand like

what modular blockchains are um what is modular IVC because this is something that I've seen like polymer talking a lot about is modular RBC how how do we like what's the mental model that we should be using to think about this concept the the main mental model is uh I think people previously had the misconception that ibc's bound to only using consensus-based lifelines and like had a very strict mental model for how the IBC stack uh was built and and worked but uh obviously is a lot more flexible than that obviously can work for modular blockchain so module IBC is kind of

describing how IBC can work for for modular blockchains and a lot of this is really happening at the the client or state layer of the problem because the the transbuilders should be standardized and then at the state layer you're connecting to let's say a roll-up on on Celestia so this this roll upon Celestia relies on Celestia for data availability it can let's say it's an optimistic roll up maybe it's Sovereign let's say it's Sovereign so there's no like canonical settlement there it can settle anywhere in fact like all the bridges to it are technically like how it settles so all of its bridges outbound over IBC um are kind of like the canonical view of that of that roll up foreign has a consensus Network this network

kind of attests to data being available on the selection data availability Network you can have a client for that saying that it will present all of the blocks that are fine that are made available on the selection Network and then you can establish perhaps an optimistic IBC connection to one of these Roll-Ups or these these Sovereign optimistic and then in this optimistic connection the way it would work is you do the handshake you post a new block from this optimistic rollup to over this IVC connection to an app chain the optimistic client will then check it has a dependency on the celestial client It'll ask the celestial client hey have you seen this block is this data

actually available if the state is available then you would start the fraud window because now you know that the data was made available on the selection Network anyone would be able to read that data generate a fraud proof therefore I can start the fraud window and then after some fraud web fraud period uh that you would like settle or finalize that block okay let's talk about this this um you said something here that I think is really interesting and I think we'll help understand where polymer sits in the stack so you said that the transport there should be standardized and we said earlier that the transport layer is where we run into the we run into issues when working across

um different uh types of consensus engines uh what does that mean exactly when you say the transport layer should be standardized and is is this where polymer sits or like if we have application layer transport and State polymer sits at this kind of Transport State layer level correct yes so the main issue that polymers trying to solve is bringing the IBC transport standard to different chains so the the way we mental modeled it is very similar to uh I guess like what I was talking about before where like you want to separate the idea of the state that you're committing to on the Chain itself so this is execution state and you want to separate that from transport state which is all the

communications in and out of the blockchain like like my argument is that these two things should be separate things like previously most I would say all chains have some sort of execution they have some like you know data store some like data that they've committed to and they have a single state route for all that I'm arguing that you need a state route you also need a transport route so polymer's main job is to commit to this transport route on behalf of uh all the change that is connected to and the advantages of this is if you can standardize on the commitment format for this this route and also use this the same data structures for this as well then the rest of the network only needs to implement the same proof checking logic meaning that you don't to

integrate a new chain it's like either you just innovate polymer directly or you have this Library where you integrate IBC as a library but use it as a completely separate thing have it run kind of separate to the chain process or the chain logic and be able to leverage the existing infrastructure without so you don't need to build a new relayer you don't need to implement your proof checking logic and have every single chain in the rest of the network adopted now everyone's kind of agreeing on the same language so it's like now everyone speaks IBC or speaks English and they can all communicate um and then like how that data is forwarded from chain to chain that that's the the consensus problem you're mentioning like if you want to verify

consists of a chain on another so so the the transport standard when you say the IBC transport Center is this a standard that exists in the IBC uh spec or is this as a standard that you guys are proposing this this exists so this is the IBC core specification so this is IVC connections channels and packets okay and um what does does polymer then make um relayers somewhat obsolete because all the transactions are just going through uh polymers transport layer no I would say polymer IBC enables a

chain meaning that if polymer is running or like integrated with the chain on the relayer side this chain now becomes visible to the rest of the IVC Network as any other Cosmos chain so I would say polymer makes a chain look like any other like IBC enabled app chain okay whether it's a cosmos chain or or any other chain yes yes that's correct okay okay cool um when so so when interacting with chains I guess like you know maybe this comes back to you know what I mentioned at the top of the show which you think

that which is that you you think that most interoperability Solutions are not uh standards but they're actually products um When comparing polymer to something like axolar you know Axel are essentially acts as a a massive sort of like a massive multi-sig right with with a set of validators now you can agree you know you can you make that security trade-off or you know and I think most people do and like I think it's fine but um how does like how does polymer differ from that fundamentally the difference isn't in the security

model in my opinion because I think longer long term every single interoperability solution will converge the same set of security models that you know have trade-offs in between them since like with you know lifetime based security is going to be somewhat more costly than perhaps just using like a centralized relayer like layer zero getting more on the the centralized side of the security Spectrum um I think the difference is when you're building this uh interoperability solution how are you thinking about the problem so I think for a lot of interoperability Solutions the way they thought about the problem is how can I like do token transfer how can I solve for this feature this this feature that feature

and a lot of the features they're solving for or application features like how do I send some messages or send some bytes and as they go down this laundry list of answering all these questions um they would be going down the same design path as uh the folks that Chris goes and um a lot of the folks at the ICF have gone through with IBC because if you want to design a protocol that you know as I mentioned earlier in the call they can do like like version negotiation uh channel channel readability like authenticated communication there's like a long list of features that as you design your your protocol you get to this like standard specification so I'm saying that a lot of these um

interoperability products are very early in their Journey they've just answered like a few product facing uh questions with with what they what they've built uh and then right now they kind of need a longer term like reconcile that so it's possible that they can convert what they've built as a product into a protocol but that's a very difficult path to take and the path that we took is we start with the protocol which is like uh the the transfer layer protocol specifically and try to work off of how do we extend this protocol to other other chains where this protocol has a lot of collaboration it has a lot of Builders it has a lot of network effects okay I see what you're saying so like so from your perspective it's like a

bottom-up approach uh whereas a lot of other interoperability Solutions are are having a more top-down approach perhaps addressing some issues that applications are facing uh by making some trade-offs on well probably I mean one the security model but also the uh like so like the long-term viability of the solution as the ecosystem converges towards standards and right by having a bottom-up approach that Implement standards first uh I mean you have to make a bet on those standards of course yeah the standards will be will be winning and I I think like you know we agree on on the standards part uh

that the the long-term uh the long-term implications are that the the standards will win out and that the applications will benefit from having all the functionality of the standard yes that's correct I think from the the product point of view is if you imagine the inside of the world being Every Chain has native IBC interoperability if every chain implements IBC natively a lot of these products don't really have a place in this world they've gone off and implemented some custom solution you know be like I guess an axillary's case they have caution Gateway protocol they have a lot of things that they

built a lot of features that they've built off of zero standards um they do support IBC because you know they are a native Cosmos chain on the on the cosmo side but they're not trying to extend IBC as a standard to these other chains so when these other when these other chains have IBC implemented they're just going to be using IBC directly then axelon no longer has its like Monopoly holding on every because like right now the way it's designed is if you integrate cgp on on one end you're not able to switch between that and IBC with IBC any chain can be a middle hop and then they kind of like lose a monopoly so it's kind of like a lot of chains are disincentivized to even uh try to make IBC a broad standard because they kind of like it weakens their position

so like the perspective that we've been thinking about it is we want to imagine a world where you do have this like neutral infra layer on the inoperability side being IBC and then with this neutral infra layer who can build the best infrastructure so it's now like because chains can switch easily between providers so like I can easily switch my channel between uh one connection versus another this would be between two two different middle hops who can build the best IBC metal hop and that and that's the the question that we've been trying to answer with polymer are there any useful analogies to standards development in like in web Technologies or the OSI model

like I'm trying to think if there's any act any interesting analogies that we can draw from other standards like I don't know SMTP for example right which is like the male standard and how there's been applications that are built on top of that or um or kind of you know different server implementations of SMTP are there any useful analogies here I mean I I still think the TCP IP analogy is good because there's a clear distinction of where it sits relative to application protocols uh earlier in the call I mentioned you know some folks have taken the view of ibc's too complicated why don't we just do like a get posting or perhaps a uh just a send bytes thing I would argue

that those are application protocols um like like those are very simple you can you can build that on top of IBC transport but that's not the only thing that you can build so you can have HTTP on top of tcvip we can have grpc you can have like a multitude of different application protocols that can be built on top and it's not just uh application specific protocols for like token transfer there's infrastructure protocols that you can build as well so like the obviously transfer exposes enough information for you to build uh decentralized relay incentivization in the form of ics-29 and I think that's just kind of scratching the surface here okay and and it's the idea of so that is the idea for polymer to become a a a platform where developers can

build applications that leverage the standards or does polymer remain this somewhat um somewhat uh agnostic platform and applications are built on the edges like what what is the amount of um products that you know you anticipate polymer to to host I I don't see Palmer as like hosting these applications uniquely or specifically I I see it more as a like infrastructure primitive so I see it as a neutral infrastructure primitive that extends or like enables IBC enable with certain chains and also like acts as a very efficient IBC middle

hop to a to a longer term vision and the reason why we even want to bring the IBC transport standard to these other changes because there are there is a lot of innovation on top of IBC transport already and a lot of these Innovations uh like ics-29 can only be built on the at least currently it can only be built on the IBC transport standard and with the Innovation at the app layer of IBC we want those to extend those Innovations to their chains so just by IBC enabling or bringing the IBC transport to a particular chain you also get all of the IVC application standards that have been created as well so as like there's if there becomes like a network effect here of like the more

Innovation on the app side drives more adoption on the transport side um and and so on cool let's let's talk about the um let's talk about zkibc optimistic IBC and uh and then uh later on we could talk about ZK man so what what is ZK IBC and optimistic IBC and how is it used so at least for the time being both terms are referring to the type of underlying IVC connection so in order to like Bridge state is what the connection is possible for britishly from chain a to chain B you can do it using uh ZK like client or ZK IBC connection or you can use an optimistic

client or a ZK or an optimistic IVC connection so it's just referring to how the the state is bridged for now and and so in in the case of um in the case of zkibc would that be used when bridging tokens over to ethereum or send any messages to ethereum or how does that work you know compared to maybe that that example we gave earlier when interacting with a you know non-evm chain or sorry an evm chain that would Implement say a ZK IBC implementation how that how that transfer work yeah so for for us we wanted to have a

default but Saints security uh model for going to ethereum so we wanted to rely on uh consensus-based security so we wanted to have some some way to prove the consensus of our chain on ethereum and there's multiple ways to do that uh we looked into doing it naively which is too expensive we looked into generating essentially a ZK proof is your knowledge proof of consensus of a Palmer on on that on a particular chain we realized that generating the proof would become too expensive so we went down this path of building ZK mint which we'll talk about soon

but the ideas he came in was we wanted both be able to prove consensus but also be able to do it efficiently within a reasonable time period you don't want to wait like 30 minutes to generate a proof you want to only wait like a few seconds so the idea is for ZK man so ZK man is like a light uh a tenement like client that can run as is can it run as an ethereum contract is that the idea the verifier for zika mint proofs can run as ethereum contract right the human itself is a is a tenement or a comic bft Fork okay so so uh if like ethereum validators could run ZK mint

um they will be able to verify the proof verify the state of a say a cosmos chain and then using the verifier that's uh sort of a smart contract in ethereum they would be able to verify that state on chain yes that's correct okay the um this are going no they're gone I was just going to say that uh we'll talk about how optimistic plays into this as well how like the two interplay together very nicely but on on the ZK Min side it is so like we have some marketing out it is uh like a ZK friendly tournament consensus but I would say that it's a little bit

more than that uh from my perspective we kind of see like the high level idea is that if you want to bridge or sit between different ecosystems right now Bridging the cosmos is like fairly simple because every chain is more or less the same it's very homogeneous in terms of the architecture but when you're going across ecosystems all the all the architecture becomes heterogeneous so in order for someone something that sits in the middle to be efficient you need to be adaptive so I as a middle hop need to be able to adapt perhaps the header format that I'm generating I'm not committing to different data this is just how the data is is structured that didn't need to be structured in a

way that's like easy to verify or easy to be verified on a particular execution environment so the zika means actual Innovation is uh being able to derive multiple versions of of a header so with the same data but multiple versions securely and allow for us to be able to be adaptive to all these different execution targets regardless of whatever we're connecting to like establish the most efficient connection possible with that with like with a high level of security Okay so if the way I understand that so we we may have uh like header formats on Cosmos and header formats on EDM chains that are different

uh what polymer would do in this which polymer access here is sort of the uh it has its own header format that it it will interpret any sort of header format that will get interpreted then by a destination chains that are uh compatible or sort of like it'll convert them back into whatever the destination chain needs as a header format so it's kind of like a translation layer also that sits between these different chains yes that's correct yeah so okay got it we're able to kind of be backwards compatible with all existing Cosmos chains while being forwards compatible or be able to create efficient connections on any number of new chains as well okay interesting and so for this to work

I mean you guys are deploying obviously ZK verifiers on all of all of the kind of evm chains so that evm chains can efficiently verify tenement consensus using this ZK mint what about other chains so what about you know say Solana or I guess near is an evm chain but like the move ecosystem or other VMS that and consensus mechanisms that are not cos close and and EDM it works just the same so the verification logic is um like you you could implement the verification logic anywhere so the currently the types of proofs that we

use is Groth 16 uh without diving into too many details on the math mathematical side you're essentially performing a few pairing checks to verify a proof so like in the smart contract you would have to Define uh all of the the pairing check logic which is just some mathematical functions and you would do this check about like three times so uh like this would be able to like verify that proof so it's something that you can Implement anywhere okay and so so the ZK uh the ZK mint is is useful in the context of ethereum uh is is the optimistic the ZK optimistic optimistic IBC uh then

more useful in the context of say Celestia or optimistic uh settlement Solutions well it's definitely useful in the context of an optimistic rollup because you need to like there's no other way to kind of uh speak directly to an optimistic rollup since since the the connection the nature of the roll-up is is optimistic the the nice copy of that we found going to ethereum was that if we only use ZK proofs so like we figured out how to reduce the verification gas cost of the verification of tournament consensus down to something reasonable reasonable ish on the order of over 300 000 gas though though uh we found that if you wanted to like do this

verification at some reasonable latency that's like 10 second 30 second latency you're going to incur significant operating costs on the order of perhaps 10 million dollars to over 100 million dollars if the network is is highly active and this is just not practical and and most folks like even with some incentives in place like ICS 29 it's possible that you have to wait forever for enough incentives to accrue to pay a 40 cost to do this client update kind of dates and the cosmos are insanely cheap like for in most cases on the order of sense uh but this kind of thing is going to be like 40 100 maybe even um so we're like thinking about how do we you know balance the cost aspect without not losing

without trading off on this on the security side we're like okay if you use optimistic but if you add an optimistic verification you get nice properties from both so with an optimistic verification approach you essentially set a Max bound on the latency that you have to wait so let's say there's not much economic activity going on you can you know post a new update so to update the state of the the client and you can wait some period of time but let's say like 30 minutes an hour and after that period of time it's now that connection is settled and you're able to transact within the fraud window you can use the ZK proof

both as a fault proof to prove that something that fraud was committed some relayers posted an invalid client update you can prove that you can also use it as a validity proof so it has a is a dual use case meaning that if I want to speed up this process so I don't want to wait the whole fraud window someone has like a really big transfer that they want to transfer like I don't know 10 million dollars and they're like oh 40 I'm willing to pay that I'll give out 40 incentives and now everyone's transactions can go through like we use a ZK proof we prove consensus by the way everybody transactions can go through so can can you talk a little bit about

um your collaboration with Celestia and how you facilitate transactions to Celestia Roll-Ups and I I specifically I'm I'm curious about you know there are many different settlement um uh sort of like roll-up Solutions on Celestia so like Dimension and uh rollouts Etc um what how how does uh polymer then interact with all of those are there different implementations for each of these Solutions or can you interact just with the data availability there at Celestia like at which state which uh layer of the stacker is polymer interacting with polymer can serve as a middle hop

between like Roll-Ups in the celestial ecosystem and and um app chains it can serve as kind of like a pseudos like soft confirmation layer so to speak meaning that if you have a bunch of optimistic Roll-Ups you could technically have those optimistic roles connect to polymer first and polymer can kind of like I guess like verify for some roles make sense it's like you can kind of do the verification so if you if you do the execution right away you can say that is this right or wrong I can soft attest to this and you know this is a but this is a different security model you kind of have to account for this so polymer can do that uh but I would say that some of our work ongoing work with a number of these Roll-Ups is to

get IBC natively implemented into those particular Roll-Ups they can also opt to connect directly so the nice thing about IBC is you're not forced to use a particular settlement layer so like if you think about the settlement layer is like where like did I finalize all of my transactions that are it is like canonical view for software rollups there's no like canonical settlement layer so they kind of settle in other Bridges with IBC you can basically use anyone you can connect directly to them if you want to run this optimistic client but maybe not everyone wants to run the optimistic client polymer can do that on their behalf so it's kind of like it makes the ux easier for chains that don't necessarily want to run the optimistic verifier for every single like roll up because like every single roll up uh the optimistic fraud proof

for that rollout may require the app change to run uh was on uh sorry um like like a wazen like fraud proof like verifier maybe it's um space maybe it's uh you maybe you have to run the whole app chain so like I believe that there's like um something that you have to generate a whole I can say IBC app sorry uh Cosmos app for that chain and we execute all those transactions to identify the faulty transaction if you don't have like a more granular fraud proof mechanism so it's a lot of overhead for for every chain to to do that okay interesting um

I'd like to maybe like talk a little bit about um about you know the the Network topology of of IBC chains and uh like currently as IBC exists in Cosmos you know we've talked about this a little bit earlier is we have a very Hub and spoke like model where you know a chain has to have um transport layers or essentially relays with all other chains that it wants to send tokens to and and you have to multiply this right times x number of chains now there there is some some

routing that can happen I believe that's um not yet fully implemented right like the routing between chains that would allow you to move tokens from like chain a to chain Zed right and like it'll just go through uh whatever chains that they can find in a passageway um like this doesn't feel very efficient right currently in its implementation what is the ideal Network topology for for IBC for that to be as efficient as possible and does polymer have a role to play in creating more efficiency between all the IBC chains as you know acting as kind of a middle hop between any IBC

transfer whether it's happening within Cosmos or outside of Cosmos or yeah mm-hmm I would say that the most efficient Network topology is probably going to be multi-hub in Spoke so if I think about like the internet you have like a lot of nodes talking to like a local router which then like forwards those uh packets onwards so this is kind of already you can already kind of visualize this like multi-hub and spoke model the work our work on multi-hop IBC is going to help someone alleviate the needing to transfer costs like a bunch of different chains if there's not a direct path between one chain and and the destination that you want to

transfer to with multi-hub you can establish a channel directly over existing connections between uh chain a and chain Zed this improves the ux a little bit you can further improve this by allowing people to perhaps like upgrade between different paths and also specify multiple paths potentially as well because then now the liveness of the path is is is better um obviously this there's some security considerations here to be made but um you you can essentially have like multiple paths like leaving uh or back in a particular channel so the channel liveness can be it can be a little bit better as well um Palmer's role in my opinion is

based on the question that I posed earlier in the in the podcast around in a world where every chain has IBC natively uh on the on that particular chain what is the most efficient middle Hop look like and our perspective is that a very efficient metal hop is going to be a master at adaptation we're going to be because if you're connecting different like heterogeneous ecosystems the middle hop has to be very adaptive and we kind of already see it with modular blockchains if you establish a new module or blockchain let's say it's an optimistic rollup then as I mentioned earlier you have to kind of expose the verification details

of that execution to every other chained IBC Network unless there's a hub that you can connect to that abstracts away those um those uh implementation details I believe that's how Dimensions Hub works with its Roll-Ups I think that if you just talk to Dimensions Hub that you're you think you're talking to like one of its Roll-Ups at least that's my naive understanding um from from their dogs okay and when when considering you know the fact that polymer sits as a middle hop and you know if polymer is successful it could sit as a middle hop between lots of different chains and potentially you know have like lots of

liquidity going through it um is it ideal for for polymer to have this in this important of a role as kind of sort of central hop where if polymer goes down or if something happens to those those um those that transport layer that essentially you know the rest of the chains that are dependent on it would not be able to send transactions anymore so it's like you know we started off right like IBC is great because it's it's a decentralized network of chains and we'll always find like some sort of uh uh um some some sort of a route to be able to send assets from one chain to another it doesn't depend on any Central

Hub and now we're sort of like you know exploring this idea of having an IBC Hub uh what do you think is the right balance there and like what how do we deal with those trade-offs yeah so the long or long-term Vision um is going to be on the order of trust minimization we you know identify that there is some issues with you know having a single Hub between all these different chains I've really changed I need to rely on on having having a leading a middle hop perfect per se uh our long-term stands for zika obviously is we want to implement all the IBC transport logic in ZK circuits so what this means is that

even if polymer is never online you can be you'll be able to generate a z at a very high level you'll be able to generate a ZK proof of this uh of the underlying connectivity between chain a and change that through polymer so if polymer sitting in the middle of these two chains it will be as if like polymer didn't like technically exist as a chain it's it's a it's a provable uh Channel path between these two chains now if that makes sense okay yeah now that I I understand so without even with polymer not being there because these chains would be using um uh polymers uh transport layer they would still be able to talk to each

other directly without polymer facilitating the transfer yeah so that's the long-term plan but I think there's like certain caveats to this requiring I think there'll be a hybrid approach I think some change will uh need like for like if it's optimistic role look like you need to optimistically verify um the the role where you need like this problem so there's like some mechanisms on a change basis maybe they can rely on 4zk so maybe like the the channel happening Two Chains can be for ZK maybe you can't maybe it needs that middle hop I think it's going to be somewhat of a hybrid model in the future hmm so what's the what's the road map and you know talk a little bit about some of the teams that are building on

polymer and what do you who do you expect uh to to be integrating polymer uh when polymer hits mainnet yeah so we expect to obviously integrate all the existing teams building in the cosmos and that are IBC enabled but what we're really trying to Target um in like soon after launch so initially we're just going to establish connectivity to ethereum or IBC connectivity to ethereum we really want to push IBC as the interoperability story for roll-ups since I imagine that in the future a lot of activity is going to move from each L1 to the various rules building on top of them and there will be a lot of uh

relapse in the cosmos in the celestial ecosystem and so on and I think that the the IBC or the interoperability story for Roll-Ups is still like yet to be established and and like obviously is a critical component of that like we need to get IBC in the op stack we need to get IBC uh in like the ethereum ecosystem and the way we do it natively is through its mini Roll-Ups because I think getting IBC natively into a theater mail one is is kind of a is probably not going to happen anytime soon um but on the Roll-Ups roll-up side it's much more possible cool what's the what's the road map for uh for mainnet

yeah so our role for meaning is we're going to establish uh connectivity to ethereum first and then we're going to Target connectivity to various um uh roll-up networks on on ethereum as well in addition to kind of Roll-Ups uh in in the cosmos sorry I mean like what's the timeline oh the timeline oh sorry um we're shooting for early next year uh we were launching we're currently in a private test net but we're thinking to launch the public test that later this year um and Then followed by by a maniac utterly next year okay cool and like can can people already start uh leveraging like early Primitives that uh polymer are building to start integrating with say the

Roll-Ups or their app chain yeah so we're planning on releasing some docs around IBC SDK and with idcsdk you'll both be able to interact with existing Cosmos chains as well as polymer and build uh on IBC transport on uh on Smart contracts on ethereum and be able to interact within ethereum and Cosmos change and so on all right cool well thanks a lot for uh for coming on that's been really interesting I've learned a ton about IBC and how it works and I hope uh people who are listening also learned more about IBC and yeah really looking forward to seeing Paul we're gonna go live and creating more interoperability between Cosmos and the rest of the blockchain

ecosystem so thanks Bob