DappCon 2023: Dynamic IBC: The New Wave Of dApp Composability - Federico Kunze Küllmer

Transcript

hi good morning uh good afternoon sorry I'm federo I'm the founder of edmos and today I'm going to be talking about Dynamic IVC and how it's going to unlock the new wave of of D composability so first a little bit about me uh I've been a cosmos core contributor since 2017 I started working as a full stack engineer and then made my way into uh working on core protocol worked on the IVC uh interoperability protocol that makes today Cosmos famous and then I transition into building an evm on top of Cosmos with full interoperability which is what OS offers today so the main question that we want

to answer today is like why is interoperability relevant and how does it affect uh developers and also users uh in terms of user experience so the main thing that interoperability provides is it allows you to use defi Legos so right now when we think about ethereum and the virtual and different virtual machines you have uh different smart contracts or decentralized applications that you can use to leverage one another and build on top of that so that's what we mean by composability so um you can build uh lending protocol by using an Oracle and so on but what happens when you don't have those defi Legos is when it becomes Pro problematic

today uh that you need to reach through interoperability to another protocol or to another evm chain in order to start using those def Primitives those defi L Legos before you get to start building something and ultimately this is a big problem because it's not only a technical problem but it's also a business development problem because today we have uh many applications that are deploying on different evm chains um and that also adds cost to the foundations or to the core development teams that the need these basic Primitives in order to start building this happens when you don't have uh interoperability in place um and that's

why interoperability is very important to be able to compose uh with one between smart contracts then uh the second major point of why interoperability is important is because it provides access to liquidity so today there are more than 160 evm based chains deployed in production and they have the vast majority of the tvl the liquidity available in the blockchain ecosystem overall so what happens today when you have um usdc that is deploying multiple chains uh sometimes you have to reach that liquidity so that's why today we think that the concept of tvl uh the

total value lock for a single chain is not accurate anymore that we need to expand this uh terminology to be able to account for all the liquidity that is fragmented and available in other chains and other ecosystem so interoperability is important to be able to reach that liquidity in the first place and finally for composability that I mentioned a little bit before but also for user experience so today you have uh multiple accounts in different networks uh different types of EV chains other types of VMS uh layer ones layer twos even layer 3es so interoperability can also provide as a mean to managing

different accounts on other networks by composing with one another and being able to at the end State um send instructions to accounts that you manage from a single like main account so to speak so that's why interoperability if we thinking about the end state of user experience inter is really important to get us there and so we talk a little bit about the importance of interoperability and how it also relates to user experience right um so I want to talk about also how interchain user experience today really sucks for end users and how it's

really hard for mainstream users to get on boarded to crypto especially when they have to on board to different uh ecosystems that don't have the interoperability in place or they have to manage multiple accounts so I'm going to provide a few examples of why this is the case so the main thing that you probably seen when interacting natively with different deenal applications is this um having to change from one network to another even though you have the same uh evm compatible chain and the same address derivation in this case the etherum types accounts or in the case of Cosmos as well on the right side that you have um multiple chains and this is

kind of like for Crypton natives we are used to it but for someone that is coming from the web 2 experience or from a banking experience maybe even for Mano Bank this is completely like it blows their mind and they don't know how to get to there like I as a user should only know that I have tokens that are located somewhere on this the the wallet should be smart enough to be able to understand where to transfer them to so obstructing that functionality is really relevant when it comes to user experience and yeah this is the the phase that they come uh when they come to the to this uh environment they download metamask and it's it's a pain

in the OD for them so the main the other thing that I just briefly touch is the token fragmentation we have different interoperability Solutions with different layers of Securities different layers of security different levels of um of decentralization different levels of governance some of them are multix valary secured consensus secured um plain multix and also uh like client base like protocols like IC in the cosmos ecosystem so that naturally leads into token fragmentation so as a in terms if we're talking about interoperability us this is one of the main pain points for the end user and as I said before the user should only care

about having usdc or having usct and not having the single like the every specific denomination in their wallet um and then we get into different formats right like we talk about Native tokens we talk about erc20 tokens and then there's different standards in like uh Tron Etc they're different so how do we make the tokens compant uh with each other and how to create interoperability so that it supports like ideally one standard or one specific format for um for the tokens and don't get me started with nftd and that's also like a different points I'm not sure for example in

Cosmos that we've uh come with a specific standard for that yet so um then the other main problem is like when it com comes to and there was a talk right before this uh downstairs about the this this standard for cost messaging interfaces between evm so trying to standardize the different Bridge implementations into something that is more that can be obstructed and so that we can provide better user experience overall and better developer experience so that we can we can share these implementation uh overhead but the reality is that it's not there there's not a strandard

implemented if we look at the reality there's like the race as I call this race of application in uh specific interoperability That was supposed to I guess try to solve this issue by having um cctp ccip um Wormhole Axel GMP so different implementations of bridging Technologies and so for some time uh there was hope that applications will come to terms in in in sort of like leveraging each other's technology and leveraging each other's open source code to create uh real standard for interoperability or for bridging at least uh in the AVM world but if we

start looking at the different implementations we can say we can see that for example Wormhole defines a Target chain a Target address pain load which is a data that we're calling on the counterparty Chain receiver value gas limits and it returns a sequence uh same with CC IP from chain link receiver data Fe token extra arguments and also with circles implementation it's more or less the same but you can already see the similarities between these different implementations for sending a cross chain message but the problem is like first they cannot even agree on the single uh type for addresses or um or

payload or the even the AR the arguments um like order that will create a different function signature on solidity or in the Avi so this creates a lot of complexities even for uh full standard to be implemented because like even the ordering is different it's going to create a different Avi uh signature so like there's nothing else to say that well how can we create a better interoperability protocol or how can we create a better structure that is able to provide with better security with better governance with uh more

Outreach interoperability Etc that can abstract the different um application specific interoperability into something that is more robust and more secure and just to highlight again this is not a technical problem um this is a business development problem more than anything else um because the the standardization is something that we need to agree off chain and it's not something that uh can be implemented in one way or another it's a business development problem but Cosmos is here to help us right there's like this amazing standard called inter blockchain Communicator

communication protocol or IVC that is able to to uh via light clients generate miracal proofs of inclusion of the transaction receiving acknowledgements Etc so what about IVC so IVC for the ones that are not familiar with it um basically Works under uh two different layers which is IVC transport which uh here it's represented as tow or uh transport authentication on ordering layer um so that you can provide the client the consent the connections on the channels and then you can order the channels accordingly and then you have the application layer basically what you

built on top uh so the end user applications or the application specific logic that is interoperable uh via this protocol that relies on this transport authentication on ordering so in reality it looks like this but it's this is really complex already for an an ethereum Dev developer for an application because uh you need to Define I IBC clients basically maintaining the light client uh aate and the consensus State for the counterparty chain then you have the connections and the channel the connection between the two chains and the channels that Define the con the connection between the specific parts of the state so it's

smart contract with smart contracts not not only uh chain with chain which is what connections obstruct uh what connections Define so at this point I lost most of the etherum developers when I try to say this um because all they want is something that they can Define and is fully obstructive for them so that they can Define send packet or send arbit an arbitrary message to a uh destination chain with a recipient address and some payload data so um this is a visualization of how IBC Works basically you have like a module or in this case in Cosmos um a part of the state that it talks to

another part of the state and for this you need encoding basically the message that you're sending cross chain needs to be encoded and decoded to be able to understand the logic behind it and be able to define the conditions for it so for example if I'm sending a transfer between uh chain a to chain B um I'm sending a payload uh defining the sender that they receive reent uh a token with a specific amount and uh some fee if necessary to the one uh relayer which is this actor that is maintaining the light clients updated um but what about developer experience I mean we've we've talked a

little bit about how IVC is a one of the most robust interoperability producs in the ecosystem today but it hasn't been able to reach to the developer like up application developers it's only able right now it's mostly applicable to chains interacting with other chains like layer ones with layer ones and not layer ones with smart contracts or vice versa or smart contracts with smart contracts like to have full interoperability across the multiple layers of the state so I want to leave this Fe feedback here that uh ADI um who is one of the main researchers from from

informal systems one of the main contributors to IVC left in this forum that these IVC obstructions are really relevant um so maintaining the lik lines because they're relevant for the security uh guarantees of the IVC protocol but they demand too much effort for developers to understand to start building and they're uh right now they're necessary before you can start shipping something there so it's not like on um smart contracts or in DVM that you can build a smart cont contracts deployed and the chain while the chain keeps running here in order to build an IVC connect or an interoperable application you need to um to build an entire module perform an upgrade and

then launch your logic what about having these interoperable smart contracts um be able to be shipped faster and and accelerate the piece of innovation when it comes to interoperability so for this is we uh we are introducing Dynamic IVC which is this concept of having dynamically Dynamic Pockets so that smart contracts can be able to send a cross-chain messages with the same security guarantees as the most popular interoperability protocol in the ecosystem today so basically what dynamic IBC uh includes is um sending the packet and receiving

the package logic I'm going to go into that in a second so why Dynam why is dynamic IBC important uh to the ecosystem so it provides complexity of struction for the end developer so that you can just Define the same packet data as what you can find on on traditional bridging structures it can accelerate the uh innovation of interoperability and composability it can provide better user experience by accessing defi Legos building composable dos and um obstructing all these end user complexity in order to build better user experience and better products it provides the security guarantees of uh

like client proofs and you can also applications can be built that are fully interoperable which was something that was not possible until today so in terms of dynamic IVC there's um the main uh the main uh parts of dynamic IVC is be able to send up pocket with some data payload that the application itself the smart contract defines and then callbox so being able to receive the data to receive a pocket coming from another chain and being able to decode it into something that the application can can um interact with so for this uh one of the main critiques to the IBC protocol and interoperability

protocols in general to be able to have interp native interoperability between between different EVMS or different VMS sorry um some of them support interoperability encoding via Json on some of them um support Avi encoding rlp encoding Json uh grpc Etc so the encoding format is relevant for the applications to be able to abstruct this functionality and create and understand the logic that is being sent or received so we're introducing as part of dynamic IVC uh a Json evm extensions to be able to connect for example evm smart contracts with coso

Wason smart contract which is one of the other main uh VMS available in the cosmos ecosystem and also Avi to Avi encoding to be able to have true interoperability between smart contracts on the AVM layer so going back to the issue around uh different interoperability uh implementations different Bridge Solutions is that all of these can be obstructed with Dynamic IVC so you can build the same Pocket Data so Target chain Target address payload receiver value uh even tokens and fees obstructed into the Pocket Data so everything that we have here can be built on top of the basic

interoperability layer which would be dynamic IVC uh so this will make it easier for developers to onboard easier for application specific uh interoperability bridging Solutions Etc that are all already built that are used by Major um institutions uh like chain link or Circle and can be obstructed in a way that um applications can Define their own interoperability logic so um I talk a little bit about the sending logic what about the receiving logic so the callbox functionality is is related

to the Octor uh functionality in that basically you allow the contract to receive the encoding data and abstruct the functionality uh um run the execution for the Pocket Data that is received and then return a value so this basically what it enables in concrete terms is that you can compose with other chains and being able able to handle the acknowledgement so that uh success or receive acknowledgements from or even timeouts are properly handled on the application layer so no matter if you if the um cross chain interaction um is successful or fails

you can even handle those cases so and this also is built on top of our um evm extensions which are stateful pre-compiled contracts um that are able to Define this functionality and have Smart contracts interact with Native um Native code in go um that we are already using on Manet to interact with the staking logic um and we're also building other cool functionality to interact with cross-chain applications or cross-chain um cross-chain application specific blockchains so atos we're building the interpretability layer uh these

interoperability Solutions as a way to provide a better user experience and composability being able to provide better on boarding and being able to provide more usability for applications than one other um evm compatible chains provide so and a main point for this is also being able to have omn liquidity so obligations being able to talk to one another and reach liquidity that is not available on the native on the native chain but they can interact with a DEX that is for example deployed on osmosis or another uh evm chain and Swap and then get the tokens back so this is crucial for user experience so that the

user doesn't need to change their wallet or doesn't need to transfer the tokens to um the the chain that hosts the deck perform the Swap and then transfer the tokens back to the originating chain these can all be obstructed for the user and build using a single transaction with the same user experience that they're used to in evm compatible networks so OS is trying to deploy all this functionality in order to become the etherum canary chain offering all these amazing user experience and interoperability Solutions so that developers can try out without any risk all these um new features that we're deploying for them so account

obstruction pass keys uh interoperability Solutions um and up and uh Dynamic IVC of course thank you very much and uh I think we have one minute or so for questions okay thank you very much for Theo uh yeah we have roughly about three minutes for questions so if anyone has yes you sir um thank thanks for great talk I think a important topic of interoperability um I had a bit more precise question about your IBC uh so imagine I imagine you are somehow trying to connect the let's say Cosmos main net

main chain with the ethereum main chain and uh for the IBC protocol to work you need to align somehow the validator set the authorities who are um um finalizing the blocks let's say so how do you do this in practice if ethereum has so many Val so there's there are different teams that are building uh like lines for ethereum that can basically provide the same Miracle proofs uh as that IVC requires but for that you need as you said economic finality in order to to do that um to be able to verify the lik line proofs Etc um so there are different uh the team that is working on

this is called polymer and basically you define different security guarantees for your light cine configuration whether or not you want um checkpointing or uh economic finality so how many uh vors have committed to the to to the recent round Etc so that you can basically parameterize the like clients in order to uh according to your risk uh profile thank you uh any other questions oh yes go ahead so on the same subject then uh how

expensive it is to validate a light clim proof on ethereum from Cosmos I I don't have the data of how because it hasn't been implemented yet on mayet um there's only been um a few test net uh intergrations but our goal right now is to try out this technology in the cosmos ecosystem there are many uh evm compatible layers uh evm compatible networks that we're going to be trying to partner with um specifically because we built the evm for Cosmos and trying to build out this technology there's also a goric which is building a JavaScript based BM uh Cosmo wasm that we mentioned before there's um

uh an avalanche based uh implementation that we can also talk to and being able to compose across the different chains and then once we have interoperability Solutions uh with ethereum main it or even layer twos because uh there's been uh a new request for proposals for from the uh optimism team to being able to implement IVC for the op stock so that will also bring interoperability to layer twos um directly with IVC