ETHEREUM IBC HUB with Bo Du of Polymer

Transcript

welcome to the interrupt today my guest is Bo D he's technical lead at polymer they're building ethereum's interr propability Hub today B's back on the podcast to talk about polymer's recent shift to the op stack that's right they're no longer building a Cosmos app chain secured by Cosmos validators they're building a chain that will be secured by ethereum and will sit on the op stack this was announced just a couple of days ago at IBC Summit in Istanbul so it's pretty hot alpha we'll talk about why they decided to do this why they decided to move to ethereum we'll talk about how polymer enables IBC for EDM rollups we'll get into the technical details about how this works and how it changes the architecture of

uh the platform and we'll discuss the monomer SDK which is a cosmos SDK for the op stack I'm also dying to find out why he thinks the real merge is the convergence of ethereum and Cosmos I also tend to think that so before we get started make sure to subscribe to get notified when new episodes drop every week and remember that none of what we discussed here on the interupt is investment advice and quick disclaimer I am an angel investor in polymer if you enjoy this content please consider staking with us we're validating on OS Quicksilver osmosis and Juno just look for interupt in the active set my guest bodu is coming up right here on the [Music]

interupt [Music] hey Bo thanks for coming back on the podcast yeah yeah glad to be back yeah so actually I mean you know for the audience like we saw each other uh just a couple days ago because we were both in Istanbul I've came back to Paris you're still in Istanbul for def connect and you guys hosted IBC Summit uh which I think was like the fourth or fifth one or something like that um I got to say like lots of great content at this conference I thought like it was very technical very in-depth a lot of really great conversations around the panels so uh yeah why why are you guys doing IBC Summit and what's the what's

the long-term vision for for this conference yeah I think everyone in the cosmos space is generally like aware of IBC maybe they don't know exactly how it works but uh they know of the technology and are generally like this is the right solution for interoperability where whereas on the ethereum side I feel like there isn't a cons coherent long-term vision for interoperability yet or a story there and especially kind of like ethereum you know road map is like scaling focused and you know rollups need interoperability uh they need to be able to to talk to each other and ideally be interoperable or natively interoperable with uh other existing networks like the like the interchain and the cosmos so the goal with IBC

Summit is to I guess educate like first and foremost uh and and two kind of like spread the word about IBC and help these other ecosystems understand the power that IBC has and why it makes sense as a unified interop story not just for the cosmos but for other ecosystems we did one at breakpoint for salana I know salana I guess his thesis now is like they don't need they don't need rolls they don't need Shing but at some point like you know they will be interoperable with other ecosystems and uh we want to make IBC that story as well what was the what was the response to IBC Summit AT break Point yeah surprisingly we had like quite a number of attendees like more than I thought because I just assume that a of people just weren't

interested in inop and and the response from the technical more Technical Community was that like even though the marketing right now is more like oh only possible on salana or like everything can fit on the L1 I think in general the technical community does agree that at some point salana could potentially be a settlement layer uh salana could do other things like da people were talking about like salana doing da and and other other sorts of things as well so it's it's you know possible that salana and also this investment in salana light client development um so there's uh there's definitely a path forward for IBC in the I guess a medium to to long-term future wow salana being interoperable with other other chains can you imagine what that would look like um we could just

use salana for everything I all chains settle to salana ethereum could settle to salana you know the Federal Reserve and all of visa and M and all the world central banks and you know even everyone's thoughts and Ambitions can settle to salana because sett scales uh you know infinitely um so you you guys actually announced uh which you know honestly I thought was surprising you know I was I wasn't expecting uh this announcement but you announced a sort of shift in uh in strategy for uh for polymer um now you know we we you were on the podcast was just a couple months ago like in June uh but I thought like let's let's let's do one now it's like you know for everybody

listening this is like hot alpha this is not been discussed anywhere else but at this conference uh as far as I know so um what's what led to this shift uh in Direction so so before I actually talk about what we're planning I would say that for the longest time we've been thinking about how to get the best distribution for the IBC technology and in general like Cosmos Tech I think like every ecosystem's Builders generally respect the cosmos ecosystem respect the builders the the the thinkers the researchers the um all of the ecosystem participants as well and in general we kind of see other ecosystems borrow ideas from the cosmos uh but not

necessarily have distribution for the cosmos Tech it's like oh Cosmos has great Tech bad distribution so like we wanted to solve the distribution problem and then on that front I would say that the initial approach was to build an IBC connection with ethereum and you know after we did some I guess like we're chatting with folks and you know thinking about this problem we we strongly felt that the IVC connection alone would not be enough so like just chatting with a theum folks I feel like if you talk to them they'll be like yeah I've heard of this IBC thing but it's kind of they're kind of like grasping at like air or straws it's just like I I don't know what it is it's just somewhere in in the in the cosmos and like I don't I can't see yeah in The Ether it's like I see this technology I

cannot feel it so like um the the connection alone and also like the the trust model of the connection which I'll get into a little bit later I also means that like you have to put something in the middle like it's it's not ideal to have this thing in the middle U so we're thinking and also like this is this would only be an IBC connection alone so we're thinking like what what would be a better way to get distribution for the cosmos and IBC Tech uh so so the shift here is that we're no longer building a a cosmos s like app chain or a sovereign app chain we're actually building an app rollup so we've combined the cosmos SDK and the op stack and and merged them together because we felt like this was the best approach for uh getting distribution for the cosmos

Tech itself since now it's not just like the idea is being borrowed the literal like modules that Builders are working on can now be plugged into ethereum or the ethereum ecosystem directly and the other idea is that as a as an interoperability hub if we want to do interoperability across ethereum rollups and like kind of like bring this IBC technology to ethereum rollups uh the best way would be to build it directly on ethereum as as as a rollup you inherit security from the ethereum domain uh you you can have like roll up to rollup communication with IBC semantics uh with ethereum uh level security so it's native IBC interoperability with ethereum security uh going cross domains another another

thing but within the ethereum domain itself uh this is the this is what I this is this is what I believe to be the most scalable like long-term approach to interoperability across like all these different rollups in different ecosystems okay so maybe just to summarize here before so when you were last on the idea was polymer would be a cosmos Zone a a cosmos SD chain with validators as we as we know right but that zone would create an IBC bridge to ethereum and and possibly other evm chains and rollups but at least like at least one bridge to ethereum and then once you're on ethereum it's like yeah all right now what right like how you

going to bridge over to polygon and arbitrum and mosis chain and I think that was a little bit like still up in the air at least from what I remember um now it it's sort of like Shifting the position of polymer and polymer is it's embedding itself within the e ium ecosystem by becoming a rollup uh not only providing an IBC connection to the cosmos so it's sort of like the other way around right now it connects an IBC it creates an IBC connection to Cosmos via ethereum where in Cosmos everything's already IBC so you don't need to worry about the interop ability once you're there but by sitting inside of ethereum it can provide IBC

connectivity with other rollups so it effectively creates like an IBC Hub inside of the evm space where all the rollups can interoperate with polymer in the same way that the cosmos Hub interoperates with all other Cosmos chains via IBC in Cosmos polymer is kind of like this this IBC Hub in ethereum is that is that a good representation of sort of the high level Vision here yeah yeah absolutely uh and that kind of brings me to like using like a high level analogy here and I'm kind of stealing uh uh Buckman's article from uh a number and Sam hard's article from a number of years ago uh describing the cosmos Hub as as a port city and I think

that's an accurate description uh I think also it's it's relevant too because IBC actually uses this port concept um you you buy like applications to Ports and and you can create like channels between them so in my mind it helps polymer establish itself as a port city for trade uh similar to the cosmos Hub but in the ethereum space so the analogy here is that uh a port city is as secure as like the country that it's sitting in if if that makes sense so like if if you know you're you're a port and you're you know sitting in the US perhaps and this port gets attacked then the US will defend this port with its you know uh military

and and in the same sense like a port docked in ethereum a port city docked in ethereum is is defended by ethereum stake so that's like myal model for it and then in like each country you have different port cities that like talk to each other if that makes sense so like the port cities act as like the lanes of like Global Commerce while like uh like in within the T ecosystem the ports can also facilitate the transfer of goods between all the the different cities uh within ethereum itself that if if that makes sense like if if all absolutely makes sense yeah yeah I mean I think that this port city analogy is is quite AP like Sunny's also talked about this too right in terms of security um you know G GE geopolitical security and like the

military industrial complex seem to be a good analogy for a lot of things in in in blockchains um so I I'd like to maybe just take a little quick step back here before we get into the details here um you know so a little kind of quick refresher on IBC which will color a lot of this conversation so last time time you on you described IBC as like two parts right there's the transport layer and the application layer and and polymer creates this unified transport layer for IBC um with regards to that when thinking about um connecting different evm chains to

IBC what does that transport layer look like and you know are we still thinking about having uh indiv idual applications for individual types of activities on chain so for instance you know if we look at IBC on the cosmos side you you have applications for token transfer you have applications for shared security you like all of all of these are the applications of IBC now those don't necessarily uh carry over perfectly in ethereum we might have like a token transfer uh appliation but maybe shared

security is different and maybe there are some use cases maybe some some applications in theory are different just because the way uh you know a theum and and Cosmos are different so how how does polymer sort of sit there in the middle ensuring that these applications are compatible with each other right so if you're making a token transfer in ethereum it will get undertood on the on the cosmos side yeah so I like the tokens themselves on ethereum side sit in a smart contract the tokens in the cosmos side the balances sit like natively in the chain itself so like that's I think one of the big distinctions it's like

this concept of like escrow accounts that doesn't really exist uh in like evm like smart contract land those technical details aside I would say that when people think of an interoperability API uh like the St like standardized interoperability API this this standardized point is at the transfer layer just just to just so we're clear here so like I like if you look at TCP IP in the in the OSI networking model and IBC and the interoperability model we see that they kind of sit in a similar place they expose a similar API which is like you get some data packets what that what those data packets mean I have no idea but you you you can you as an application go figure it out um and you implement some some some features so uh

yeah Palmer just does that so it makes sure that the like below the bytes level so once the application has composed some bytes that it is transported between the chains meaning that you have to enforce all of the messaging rules so that you can enable features like acknowledgements timeouts and so on uh in a standard way across all these connected chains um above that level so like in terms of compatibility uh the you can create like ic2 like smart contracts that essentially enable uh Communication in a single Lane so I kind of see like IBC channels as Lanes in a highway so like a obviously connection is a Highway um and these are application specific Lanes so

it's like a high a lane in a highway that says only cars of this type like only Mo motorcycles or like only uh like buses um and you you kind of see these Lanes on on the street or like only bicycles or only pedestrians um and for ics2 contract because it gets bound to a channel uh the thing about ics2 that I think is like relevant in my mind is that if you the main difference is that you have fault isolation on a per Channel basis so for your application for the security model model that you have picked which in a modular security World security is non fungible like whether you used a consens whether you verified consensus between two chains that is not fungible with uh a chain

link Oracle or some sort of uh some sort of offchain Guardian set observing this like these are two different things um and because these are non-fungible you have fault isolation on a per token basis so like between so with between uh I guess this like token contract on ethereum and maybe like a like a token like the I guess like ics2 module on the cosmo side between those two uh where like kind of polymer enables this connectivity you have this like Lane that is Untouchable by any other types of transactions it's it's only token transfers between the two and generally this is not how other inoperability protocols work especially in in the E theum side it's like you you spend up a token contract you give it access to some sort of like uh Gateway or import

contract that the other interop protocol has and it's just one fat Lane for everything and and it's like it's just it's just it's just a lot going on you kind of have to do all these all these checks and and balances for yourself okay yeah I see uh let's let's um let's transition then into yet the op stack and polymer so um polymer is going to be a roll up that leverages the op stack it was interesting because when you announced this just before I was at like this optimism event learning about optimism and the op Stacks like I I I I mean I don't know a whole lot about the op

Stacks so maybe it' be helpful to start with an over an overview here um of yeah what exactly is the op stack and what's this concept of a super chain and yeah so so I think the the marketing of op stack is very like kind of like similar to uh the marketing of the cosmos SDK and the interchain so it's like Cosmos SDK build your custom app chain be a part of this the interchain and with OP opack it's like build your app rollup and be a part of the super chain uh the marketing is very similar uh so let's get into technicals um is the super chain kind of akin to the cosmos Hub here in terms of shared security or or is it not so in the super

chain model I guess the Hub the cosmos Hub would be ethereum and and like the uh app rollups would be like um like IC secured like interchain security secured chains except they use uh like a a settlement mechanism instead of using a uh I say like a shared validator set I guess with with the interchain security model okay yeah so like to me like IC and like IG layer is like active validating Services uh so like reaking secured Services is like similar to Interchange security um and uh the settlement model is is a little bit different but yeah like at a high level it's like the Hub and

ethereum the L1 are like the same Hub is the heart of the interchain and the uh e L1 is the heart of the super chain okay and then uh applications use the op the op stack to to deploy rollups and these rollups can be VM rollups they can be Cosmos SDK they could be like a move VM like the the type of rollup the the type of VM isn't like the op stack doesn't prescribe the VM right from the marketing perspective yes and I think that is the intention uh from a technological perspective I would say it's a lot trickier to integrate just some random execution engine into

the op stack we're in the process of doing that um the the the problem is that the like one the engine API so the ABCI they try to kind of make it generic between like you know some random State transition function or application and some random consensus mechanism for the engine API they're also trying to serve the same purpose it serves the purpose of separating uh the consensus layer actually for of the theum L1 of the yeah the theem L1 from the execution later of the theem L1 when they did the migration or when when the the went through the merge the um original L1 became the execution layer and they overlaid on a consensus uh layer Network and the engine API

actually is is is what separates the two so engine API ABCI those two interfaces serve the same purpose uh the engine API is somewhat generic uh although there's a lot of like the only current execution engine that's like natively supported in the cosmos esate co-base is op gu or like op's slightly modified version of the go ethereum client there's a lot of like eth isms like in the op stack so like past so if it were like completely generic it would be seamless to just plug in anything as long as you like implement this interface you're done like you ever never need a crossover into the op stack can change anything however there's a lot of places that expects like an

ethereum block and like I mean it's it's it should be kind of obvious like a cosmos SD chain does not produce an ethereum block there's like a whole bunch of fields and like things that just don't make sense in the context of a SDK app chain um so there's quite a bit of work to to to make them compatible okay we'll come back to to the technical bits here um but yeah first like let's talk about uh what the what this rollup like so so this roll up we described earlier that sits uh in ethereum um how will this rollup interact with other um how will this rollup Implement

IBC with other rollups like arbitrum or optimism or you know maybe maybe also I I mean will it interact with say other evm l1s like for example agnosis chain I think I would consider that to be more of an L1 because it has its own value valid set although I believe it does do some kind of like shared settlement with ethereum um yeah how how will that all work so polymer itself the functionality has not changed necessarily so the original idea with polymer is that uh it's it's difficult to expand IBC Network so like the the main blocker with expanding the IBC network was it's difficult to implement IBC so

like it takes time and also you have to convince this other chains like developers to say please put this on your road map or like I created this PR for like like up please Upstream this and if if they don't do it then you get into the cycle of they keep changing their code and then you have to kind of keep this like update in sync with with their updates as well it's a long process um you have to get Buy in there's you know this is not permissionless this is very much a permission process to to do that so the idea of Palmer was like how can we Palmer was trying to answer the question how can we expand IBC permissionless and to to do so we created an internal protocol called virtual IBC we essentially represent the chain

that's connected at a high level what it does is it says that like the question that it answer is like do you need to execute the IBC Logic on the original chain and what we realize is that like you actually don't need to do that you can have polymer as an interoperability Hub take on that responsibility for you so you still form this connection in in like a logical sense between this uh I guess rollup and and and polymer except the rollup doesn't execute the IBC logic polymer executes the IBC Logic on the rollups behalf and what sits on the rollup is a smart contract that smart contract acts as an interface uh there's only the only points at which the rollups application code and the IBC interface are are at

the channel level and at the packet level so you have the concept of a channel life cycle and you have the concept of a packet life cycle so when an application calls into either a channnel life cycle method or a packet life cycle method these calls actually get propagated to polymer and it gets validated using the same kind of like bidirectional client logic so there's still a there's still connection there's still a bidirectional client in this case ethereum is the verifier so like you're not saying that you're verifying like rollup a or like rollup B is verifying each other's consensus there's no consensus for rollups the rollups are settling onto ethereum each rollup has I would say like trusted access to the L1 State itself meaning that every rollup blocks are derived from the layer one

state if that makes sense so so like there's no like we don't need to verify termin consensus we actually don't even need to verify ethereum consensus we have we we already have access we already have like the the state of ethereum for free so with this client uh verification which is very very trust minimized at this point like you're you're basically just using the the L1 State you can say that uh I observed some transaction happening on this rollup to call into the IBC logic and you bind the call so now the calls a synchronously bound to the to the IBC logic in in polymer and then polymer now forms a connection outward another roll up so you can either have like a connection uh like connection between like a rollup and

polymer and another rollup or you can have a connection between a rollup and polymer and back to the cosmos now you can imagine like if you're if you're a dydx or your a nosis chain or some other um chain that's not uh I guess like IBC compatible uh you can still have connectivity IBC connectivity to to e theum rollups over polymer over these connections okay yeah this is starting to make sense so so polymer so contrary to like so so in in Cosmos you have like a chain that initiates a that sends a message let's say for like a token transfer um that that chain um sends a message to the other

chain there there's like the the tokens are escro that chain sends a message to another chain via a relayer that the other chain receives that message and then uh a um a validator will will do a light client verification of the other chain to make sure that that that those tokens have been escrowed and then sort of issue the tokens there on that side and so both chains are interacting with each other in that sense whereas here chains are interacting with a smart contract and then polymer is polymer is serving as the intermediary that is verif well that is checking the state of

ethereum um that's checking let's say with a light client the state of ethereum verifying that that that there's been a commitment on say like the sending chain and then send a message to the receiving chain that that commitment has been uh that you verified that commitment M and so it's acting as a trust layer between the two interacting chains by leveraging like the the security of ethereum that we get for free so I wouldn't say polymer is a trust layer so like there there's no trust in polymer here uh the the trust is actually just in ethereum polymer just implements IBC as a feature so like

polymer is more of like an IB like a feature layer if that makes sense it's it's like polymer adding IBC as a feature to ethereum and and its rollups the the trust layer is ethereum so even the yeah so sorry trust layer maybe was not the right so but but as a I mean polymer still polymer's role is to provide this feature of attesting to the validity of of this of of these transactions being settled to ethereum um I I guess why like why wouldn't chains be able to do this themselves

like why couldn't chains I mean I guess polymer sort of like creates this function right creates this feature uh it creates the the functionality but if chainsa got together and said we're going to implement IBC they could do this without polymer they would just have to sort of agree on the way to do it right they would have to S like yeah but but but they could potentially do it without without polymer providing that feature if the entire evm mstem sort of like agreed on a standard way to do this yes and and and that would be ideal so like ideally uh you know us bringing the technology to to ethereum that they kind of see the power of it and a lot of

these rollup Frameworks decide like you know what I want to implement IBC like I think IBC is the right thing to do because what a lot of these rollup ecosystems are doing right now is implementing their own like random bridging protocols and that's going to create more fragmentation and in this world there's two options here so now like in this world where let's say everything has IBC IBC is everywhere um if IBC is everywhere then what polymer serves as is a routing function so it's like does it make sense to connect directly if it makes sense to connect directly then some chains will connect directly if yeah CHS AR aren't always necessarily required to connect directly if there's like millions of rollups well all all a million rollups connect directly not likely like some some rollers will decide like you know what I'm just going to connect to an interop

Hub and like the interop Hub will provide me connectivity to everything else yeah no I think I think the I think it's useful to have hubs and I think polymer can carve out uh um can carve out a position as an important Hub like a port city right between Cosmos the cosmos equal system ethereum from this perspective um when when it comes to when it comes to so H when when when thinking about um you know in our last conversation we were talking about sort of like some of the challenges of implementing IBC between say a cosmos chain ethereum and that was this this

finality um this issue with finality where Cosmos has single stof finality ethereum has like doesn't have single slot finality and so um it it that's one of the reasons why it's difficult to validate to sort of like verify the state of ethereum and have like an atomic sort of style transaction um for for rollups that have a uh like optimistic rollups that have a fraud window um how is that going to work do do do we have do we run into sort of similar issues here where potentially uh a a fraud proof being issued like later would cause some issues in terms of transaction uh transactions being

verified yes so if if if there's a roll back then the um I'll say like the entire view will have changed and that is a risk so ethereum rollups uh have this concept of different rollup heads it's something that like you know Cosmos folks aren't probably like highly like unfamiliar with and they have this concept of like a safe of an unsafe safe and finalized head so the unsafe head is where blocks are just being produced so you send some transactions to a rollup they produce some block that block is not associated with an L1 block which makes it unsafe uh there's a safe head which says okay

this block actually the block data has been published to some data availability layer and like the definitions here will will change in the future with like kind of you know more modular chains but it's confirmed that the DA has been made made available uh and in the in the theorem context it's it will also confirm that like at least one checkpoint has passed or one justification which is part of the theum consensus algorithm and the finalized head actually checks that like two checkpoints have passed ethereum's view the L1 view is finalized and this is at the point at which the uh the rollup inherits reorg resistance so now this view will never reorg uh but it it doesn't stop it from being invalid so if if the view is invalid and

a fraud proof is submitted between that point and uh I guess the the end of the fraud window then that view will will change either it will freeze or or you do something something to this so there's still the problem of on the uh I say Cosmos side they would need to still run an ethereum client so the trade-off here is we're focused mostly or more on rollups for for now just kind of get getting connectivity across them going to the cosmos you would still need the cosmos chain to run an ethereum client so to verify that ethereum consensus is is is is a certain U you know has been validated and then you would also need proof that uh you know polymer will verify the fraud window for you know all

the its connected rollups for the IBC client here in this context if it's optimistic CL you have to configure some I say like acceptance period so like maybe you don't want to if you want to rate the full front know you can do that it's it will be a lot more secure you're just waiting like it's going to be a very slow connection it's like a you send something it's going to take seven days um it's like it's like uh 56k modems for blockchains yeah yeah but but you can have like like soft confirmation mechanisms uh either from you know like using the sequencer signature itself uh well or like the the sequencer uh pre-confirmation themselves uh that will kind of allow you to get faster connectivity but then you're trusting the sequencer so the the

trust model is like not ideal um or you can kind of have like a smaller fraud window where you can say like I'm okay with waiting a day waiting three hours um like like some configurable level of security there and the other approach that we've thought of is you can have like an ABS or like active validating service on igen layer validate or act as a precon confirmer of the rollup itself and attest to validity so like once data has been made available which can you you'll know this information with high security you also will know with the security of the ABS that that execution was correct so you can kind of balance like like these two

things and check these two things to to know that I got a message okay um so for so for in this context uh a a cosmos chain receiving tokens from a like an optimistic rollup the the cosmos chain would have to run a client or would could could polymer serve that purp because I mean then it sort of like creates this extra burden on Cosmos chains to have to run this extra client and potentially you know every chain has to do this if it's connected to polymer yes could could polymer uh give

some sort of assurance to Cosmos chains or like take on or like could some other actor take on the risk um yeah I I think it could be the cosmos Hub I think the cosmos Hub could run an ethereum client uh this kind of makes good on like the cosmos Hub being the port city for the interchain and and polymer can focus on being the port city for ethereum if if that makes sense right but then that means that any any tokens going from an optimistic roll up to say osmosis let's say osmosis is not running a client or like you know some kind of more obscure Cosmos chain right it it still has to Route like we need routing from that thing to polymer to to the hub to like that other chain potentially so it's

like probably four hops to get into Cosmos yeah but but it's it's pretty straightforward from a technical perspective uh once so the the blocker here is multihop IBC channels this is not multihop packet forwarding multi-hop packet forwarding is not ideal like you don't want to do token transfers like this you you you have like you basically have like four different like flavors of this token and you're like transferring it like four times across different chains in this model this is where multi-hop channels make a lot of sense so you will establish a multi-hop channel between the optimistic rollup and the um random like uh SDK app chain anywhere in the interchange uh directly so you have this Channel and then you'll just send the token directly across and the the you just have a list

of connection IDs uh beneath this channel okay yeah that makes sense yeah you can s them out so like let's say you wanted to so like the first connection will denominate the connection between the rollup and polymer the second connection will denominate the connection between polymer and the Hub that second connection you can even switch so like let's say you start with s days like super secure and at some point like oh maybe the ux isn't that good we we're okay with like one day you know like like like a more like one day finality so one day weight period for a fraud proof so you can switch it from like the 7-Day client or connection to the one- day connection you just do a channel upgrade um and then you'll have uh like a different

path with different security properties uh and you can have like different uh providers too like let's say you wanted to like remove the cosmos Hub as as as a middle hop like maybe there's like maybe the chain decides to implement or like add ethereum client support themselves then they can remove like hops in the middle as well as as as a network scales okay interesting and yeah so this um this multihop channel uh IBC do like what's the status on that when do we expect that to be be be live yeah so uh we wrot the spec uh some time ago

we recently or semi- recently got the spec merged officially into the IBC repo which was it took it took a long time there were a lot of reviews I think it might have had the most feedback out of any IBC spec review in in in in the history of the the repo itself um the implementation we have a PC implementation we're using uh for like IBC go we're using that implementation ourselves the we're planning on upstreaming it so the IBC go team has started taking a look at it I believe they have it planned for Q2 of next year um but I am not entirely sure uh but yeah they have it on the

road map and then they were planning on upstreaming it so so just in terms of simplifying like I IBC infrastructure in in Cosmos I mean this would greatly reduce like if say like the Hub and osmosis and maybe like another handful of really you know maybe dydx like a handful of really big Cosmos chains you are insuring connections to lots of different U Cosmos app chains than say like you know I don't know Juno or um agoric like they don't have to maintain IBC connections with every other app chain as long as they're connected to a hub that is you know

providing the connections to those chains so it it removes the burden potentially on um on sort of smaller app chains to to do that work yeah yeah exactly and then you don't have like this problem of in the complexity is going to grow like in in a Cambrian sense for uh operators um if you need to maintain direct con directivity connectivity between everyone especially with all the number of like different rollups spinning out and there will be a lot of these like more like smaller rollups and like roll apps that would need kind of like this this connectivity so I think uh I think overall did it improves the network topology okay so so one thing that's still unclear is

like why why build it as a rollup why I mean you you could have built the O like you could have built an evm or like an OP stack uh on top of say the cosmos SDK or or have that work directly with like tendermint consensus and like a cosmos validator set right like what what was the benefit of bringing it uh as a roll up like do do you benefit [Music] from um being also shared on uh secured on ethereum or does that does that make it technically easier to implement this I mean whereas you could have also just

had like an ethereum client on your Cosmos SDK chain like tender validator set right like verifying the state of ethereum and still providing this functionality to uh evm chains yeah just curious like with the sort of like technical reasoning for becoming an OP stack chain yeah I mean you could have the issue with the issue with that is that you're changing the trust model of the connectivity for rollups um like if if I'm a rollup Builder the the point of building a rollup on ethereum would be that the rollup is kind of trust minimize uh in the same domain communicating between each other when you add uh additional like third party

validator set the trust model now changes now you're trusting some like you know validor set much weaker security so like Axel Wormhole I I guess the union also is taking this this approach like the without talking about the other properties of these change is talking about like just the trust model um and also even like chainlink ccip I also considered kind of cci's like Oracle set as like a thirdparty guardian set so the trust model of this connectivity is is is less than ideal of of course like you can still use uh like some like third party Guardian set for like a soft confirmation mechanism but the default level of security I think should be like verified by ethereum in in this case so

that's why like but previously when you mentioned that polymer is like a trust ler I'm like no the approach now means that polymer is no longer ER trust layer which is the whole idea of like why we wanted to do this in the first place um and and the idea is that like polymer is just a feature layer it's an IBC feature layer um and also like a I guess like a router or Hub hub for for even like worlds that implemented natively um yeah so that that that's so it's actually you know it's more work to to you know move this Tech to ethereum uh but we believe it's the it's the right approach okay no that makes sense I think you know also from s you know a narrative perspective yeah I I think there are still a lot of you

know we talked about this earlier I think there's a lot of challenges still in having IBC being accepted in in ethereum me yes because it's because it's a technology that comes out of Cosmos people associate it with Cosmos there may be some uh some some biases there whether you know known or unknown but I think that there will be it will be a challenge to get IBC uh to be accepted by teams working on EPM chains so there's a lot of Business Development and yes evangelism to do there but if you're already being secured uh by ethereum then that that trust barrier at least uh get is greatly reduced because

you're operating on the same security your evm aligned all all those good things right that like people in the evm world tend to I really realized this like this week being at def connect just the because I don't spend a lot of time in ethereum so much anymore and going to ethereum conferences but there there is a real like sense that people in the evm world and sort of the ethereum world want to be ethereum aligned and being ethereum Aline I think is for you guys like uh a a good way to gain mind share um if is to be successful yeah yeah you touched on a good point it's it's like you need to be

able to convince them that this is the right technology in the in the first place uh and make that technology like tangible for the for this like ecosystem of Builders the the other thing that I've kind of noticed is that both ethereum and the Hub have kind of taken a minimalistic approach to the L1 so the Hub pract is Hub minimalism they don't want to put smart contracts on the Hub so they have Neutron they don't want to do liquid sing on The Hub so they have stride um ethereum in a sense has done some of the same from from a from like a scaling perspective like originally they had charting on the road map they were like oh well you know we have later twos later TW are going to handle scaling for

us and then etherum kind of just focus on data availability and also offering settlement and like by them practicing this like minimalistic L1 approach it means that like if you want to add a feature like IBC like how would you go about doing that and like from a from from this perspective it's like yeah well in baking in IBC as a roll up onto ethereum is essentially enshrining the technology uh into the ethereum ecosystem or into into not into their minds too but like into the the tech stack of like ethereum yeah right so not enshrining it directly on the L1 but uh making it available

via a rollup um keeps this keeps aligned with this minimalistic uh pH philosophy with regards to say the Hub or ethereum but still allows evm chains to interact with FC okay that's that's cool and this features is still secured by ethereum stake so it's like yeah you now ethereum has a new feature it has IBC and this this feature is secured uh yeah so so go so so polymer will use uh ethereum for security and igen layer as well for for for data availability I mean I saw that on one of the slides I saw the I layer logo

there what's the yeah how's that going to work yeah so the idea is like we want to be as secure I guess as as as much as possible like secured by uh ethereum stake um in IA being secured by ethereum stake or a restake ethereum uh kind of you know Works its way the in the same sense I I kind of see the and it's more this is more of like a scalability thing uh if if the cost were lower we we just post the call data to the L1 I think like uh that's that's also a viable approach in fact that's what we're doing on on testnet right now we're not uh we're just posting uh I would say the

cosmos transaction data as batch data onto um onto the ethereum L1 until like d test net is up okay and so you'll be posting that to to Igan layer on Main net yeah or I da yes okay yeah to ig DA got yeah IG I think has a 10x more throughput than the ethereum L1 even with Proto D charting so I think there's just more bandwidth as well okay um yeah when it comes to

[Music] um when it comes to the op stack you were talking about this uh this Canon um thing in in op I don't I'm not exactly sure what it is but um you were talking about like the the the sort of like fault proof system and you were mentioning some vague uh acronyms like myips and risk V that I have no idea what that means what what is all this about because it's like one of the slides in the deck and um just curious what why is this is relevant yeah so the relevance comes from needing to prove the validity of

the chain so if you're and this is probably something that you know Cosmos app chain folks AR just aren't familiar with um because in the app chain world you have a validator set and the way you prove validity is you can say that these 100 to 150 validators have processed this or a super majority of them have executed this code using this state machine uh and they got the same result so they can all agree and and we're fine uh on if you're a rollup uh the rollup can execute this but that execution is untrusted how does the layer one know that what you executed is is correct so there's multiple approaches to this there's ZK approach I think ZK is a bit of a meme now but um it it it is it does work in terms of verifying that an some

execution was performed correctly the other strategy is to use these optimistic fraud proofs it's to say like you have some sort of like weight period during which someone can challenge a state transition say that I was watching the chain and that that proposed block that you just made is not correct uh but how do you know that onchain so this is the tricky part what they found was that uh you can't just put your application rewrite your entire application in solidity and just re-execute a transaction uh that would mean like rewriting the entire Cosmos SDK app in solidity and have the functionality oneone which it will never be because

internal data structures are different so this is pretty much impossible you can't do this um so but what you can do is you can say I can take this program I can cross- compile this go program which is essentially what you get with a cosmos SDK uh app chain is like you just it it compiles down to some code that's run in uh in go in the go runtime so you can cross compile this go program into a different instruction set so you can cross compile into myips and the reason why they chose myips I believe is the myips uh memory and and layout is is a little bit simpler um maybe the op codes maybe there's fewer op codes I think fewer op codes like simpler memory layout is is is is a better fit for for this sort of thing um

and you can also do RIS V in the future right now I think myips is the only one they actually have an implementation for so now that you've cross-compiled your Cosmos SD app chain code to to this other like instruction set you can say that I am going to essentially look over so you have this like list of op codes and it can be very large from the beginning of the program to the end of the program so you're you're G to say I can look for the faulty op code within any of these op codes that produced the incorrect result so a computation is a chain of like I executed an OP code something changed is it correct so like if you chain all these op codes together

you get the final result of a state transition you can play this they call an interactive verification game so on chain you're actually emulating the mips VM in in a smart contract and you're stepping through all the op codes in a binary search way so it takes a log in steps if the height if the number of op codes is n um and you just search you say you go in the middle you go you know is is left or right and you kind of just like keep looking through until you find something that find the exact faulty faulty op code and once you found that you can say that this is this shows that fraud was proven if the end result and the beginning result do not match at some point there is something uh some something happened that that that was that was invalid if that makes

sense uh I'm sure it does I think it like this flew over my head a little bit to be honest but but that's okay you know I we we push the boundaries of like you know technical explanations here on the show until I start understanding them and so you know this is just we just hit one of those boundaries yeah it's basically say like you ever played telephone um yeah of course yeah okay so like when you're playing this is not a great analogy actually but like technically it's like when when you're playing telephone you're like transmitting the same thing and you at some point in the line of telephone someone's going to like like mess it up and be like now the result is going to be incorrect so like you start with an elephant and you got like a donkey and

then like who along this list like line of people like communicated the wrong thing or communicated something incorrectly so that like the end result was Donkey because at some point people started thinking it was a donkey and then like the list of off codes is kind of like that it's like at some point there's an offo that that like completely did something like like undefined actually wasn't respecting the behavior of the VM it just did like from here toep this step to step this step I just you know I changed it I went from a like a um an elephant to like some like a donkey like another animal so like like that's kind of like the the analogy in my head okay so well you you also talked about this this monomer SDK so what's what's the idea

here so the high the reason why we named it monomer first off was uh a polymer is formed of multiple monomers so if you can think of a polymer connecting uh many so the mon can build these app rollup chains that are like Cosmos app rollups on ethereum but you can think of polymer like if you compose many monomers together connected by polymer they become a polymer so so that's kind of like the thinking behind the naming so so monom is just a combination of of two different Frameworks uh Cosmos and the op stack uh the idea is that the op stack itself you know lacks as we

discussed earlier in the podcast kind of lacks this customizability it's it's it's kind of hard to build like your own custom app rollup it's pretty easy to just build another uh evm rollup and then deploy smart contract on it but maybe not everyone wants to do that maybe some people want to you know make some optimizations that are like application specific so to actually be application specific which framework has the best developed ux community docss in in globally speaking and I I mean I I think that's Cosmos s I'm I'm a little bit biased but I think some of viewers probably biased here as well but um the cosk arguably has one of the best if not the best Dev if we combine the best Dev uh with like these the settlement

features of the op stack we can address a much bigger market and We Get Much Greater distribution for the cosmos technology and long term it honestly makes sense more to me that I would expect to see more like Cosmos SDK like or basically monor SD rollups than just generic like evm like some random virtual machine with a smart contract on a rollup because like these like uh VM rollups they're not differentiated there can only be so many of them uh like like at what point does a like 50th evm rollup become like not that interesting yeah um so what you're saying is that rollups will be applications basically like each each rollup will be an app

yeah yeah like application specific rollups I think long term we'll see a lot more of that as like you know these applications want to differentiate um and want to specialize yeah and as long as uh as long as like op stack is sitting underneath it providing some sort of composability or like IBC is uh exists between all of these rollups either via polymer or just by the fact that these are using monomer and IBC compatible out of the box then applications can be like rollups can be applications uh in the same way that you know we have websites and those are like you know Sovereign applications to some

extent right like in um containerized applications and and we don't need like another you know another rollup with a bunch of apps on it like each each app can sort of like be each rollup can be an app yeah yeah so I guess the the my mental model there is like do you want a uh so some applications like are okay being co collocated like like co-hosted so in in in different cloud services you can have like a um like many different like Docker containers essentially share same Hardware uh but some applications want to be like by themselves yeah um and like they want the performance or they want to kind of like be more specialized doing

some uh to to or just be bare metal um in those cases like I kind of see like those as being kind of a different so like you have some like stuff that's collocated some stuff is going to be uh um like guess like deployed uh or like like bare metal essentially so the monomer SDK will have uh the it's the cosmos SDK with all of its modules and it's sitting on top of the op stack and so you know instead of having tenament consensus there it it has the op stack where it's like uh committing to the op stack uh so it can have governance it can have like you can create tokens it has like yep all of the all the functionality of the cosmos SDK I guess maybe like the staking module is no

longer necessary or like what about the modules that are kind of specific to the fact that we have a validator set so so uh you can actually have both uh and this is an interesting concept so um I was planning on writing like a blog post exploring this but I kind of see like the ABC boundary as having like uh the client ABCI client being on uh the op stack you know side the boundary uh the ABCI server being the cosmos SD app chain um on the other side I can I actually see there being multiple uh I would say like apps or ABCI servers and multiple ABCI clients running at the same time so you can I can see op stack and

and Comet bft running at the same time the comet bft would provide kind of like a like what I mentioned earlier like this like soft could potentially provide soft confirmations and the uh I'll say the cosos SC sorry the op stack is then providing settlement logic so you can still have like a staking module except the staking module is like staking for pre-confirmation instead of like staking for ult for like final security so final security uh is is is ethereum so like there's there like a lot of like hybrid things you can do and I think like longterm there will be a lot of like this this whole thing is is is is in the concept of like a blockchain operating system yeah so what is a blockchain operating system what does it look like what are all the components um to me

like a blockchain operating system in the sense of a rollup is you have like many kind of like client side things which act as like the blockchain kernel and you have many like application side things that act as like the blockchain user space um and and the two of those would kind of interact you have like a bunch of stuff in the user space like it might be one Cosmos SDK app chain it might be that plus IBC um and then on the other side it might be uh like you know op stack settlement um and and like com BF or some other consensus mechanism and so on interesting what what's the go to market here we talked a little bit about this earlier like the challenge of building IBC mind share within the evm ethereum aligned

Community uh H how do you plan on doing that yeah I think it's going to be from I think with BD there's there's two strategies uh there's like bottom up BD and there's like top down BD uh in my mind the way I think about like top down is top down is like your applications so it's it's spey directly with applications like why they should use IBC like how's it different uh and so on Bottoms Up is from the infrastructure layers even by putting IBC onto ethereum in the form of rollup is a form of Bottoms Up Ed getting distribution into additional rollup Frameworks onto on ethereum is also bottoms up bottoms up Ed I think even monomer SDK is bottoms

up ed meaning that the more like natively interoperable IBC rollups on ethereum kind of spreads that IBC mind share so those are the kind of like two like dual-sided funnels that that we that we need to need to work on okay yeah I mean this is really cool I mean because like it I I feel like it merges Cosmos and ethereum in a way you know we we can we can now you with monomer SDK we could have CMM applications uh in ethereum you provide a way for people to experience uh CMM uh but but secured by ethereum chains yeah what what do

you what do you see as the future here in terms of you converging ethereum and Cosmos and what's the the role of polymer there yeah I kind of see polymer as being the the Catalyst or trying to catalyze the the merge like the literal merge of the two ecosystems I think people have been talking for some time about like Cosmos and ethereum kind of coming together um I think like merging at this inter with this at this interface at kind of like this ABCI interface uh merges the Technologies uh like very much in in a literal sense so it's like uh uh like the real merge wasn't like ethereum's um kind of I guess consensus and execution lers merging in like E

theum I guess 2.0 this is uh the real merges between the the two ecosystems essentially you have like this growth actually of the inner chain like a ethereum itself kind of becomes a part of the inner chain and in the interchanges expands and like this this is I think a big step in the direction of and I think we have to get here a big step in the direction of in at some point Builders like can't and users can't know like what ecosystem they're interacting with like they cannot like if if like me as a user had to be like Oh I'm using an app do I connect to Google cloud or do I connect to AWS like that is that is like absurd like like no app works like that um so

like polymer can kind of help like form this like unified API and also like merging the two Tex Stacks together and Technologies together so we kind of have this like uniform like web 3 like API for you know builders for um I guess uh like applications building on top to to be able to deploy anywhere and just be a not have to worry about uh whatever uh specific ecosystem that they like like stuck in essentially no one's stuck everything's seamlessly interoperable that's the future everything seamlessly inable um at least it feels like we're on the or on the cusp of of of getting there I'm really hopeful that in the next you know three to five years uh

that this interruptible future that we've been talking about for years um will become a reality and and and I think that with Technologies like this and like other interoperability solutions that are are innovating um uh on on all sorts of fronts right and you know like we've had a lot of them on here on the podcast um I didn't want this to be an inability podcast although it is called the interop I was like you know that wasn't the idea but it just feels like there's just so much Innovation happening on on on uh in in this vertical that um it's interesting to like get everybody and just look at all the different approaches but I I I like this approach um uh I think it's uh it's like uh it's like an IBC vampire attack on

ethereum you know um but um yeah what's so what's the road to main that yeah so we're currently targeting testet in December um we're probably you know privately on board some partners then we most likely like announc that in in in January or so um just cuz December's kind of like a dead dead time for for this sort of thing uh and then in terms of the main net launch we're targeting Q2 up next year cool well thanks so much for coming back on again uh it was great uh I love diving in to this kind of stuff and uh thanks for having me at the IBC Summit I really enjoyed uh our our panel there I

think people will want to check that out once it's live once it's on YouTube I did a panel with uh with Carell of Union and you and it was it it was it was spicy at times uh but was really fun so really enjoyed that as well thanks so much yeah awesome thank you cheers