Welcome to the Institute of Crypto Anarchy.

Next up, we have Crossing the Interoperability Crossing the interoperability bridge.

A deep dive into building interoperable DApps with IVC.

I usually ask our team why we're doing things.

And we're going to talk about building applications that are interoperable.

Federico, do you want to give an intro to yourself?

I've been in the Cosmos ecosystem since 2017, where I started first building the Cosmos SDK and later was part of the core team that shipped IVC.

IVC is an inter-blockchain communication protocol that powers most of the interoperability in all the Cosmos ecosystem.

And today we're going to be doing a deep dive into how Evmos leverage IVC in order to build smart contract interoperability.

So after that tongue twist, crossing the interoperability bridge, We're going to do this deep dive into Ivc and how Atmos comes into this game.

Also, maybe originally we had planned to do a workshop that's hands on.

But since it's the last day, And probably everybody's already started hacking other projects.

We have more like a presentation format, but we have a bunch of tutorials online.

And we're also going to play a video in the end.

So today we're going to be talking about why there are so many chains, why are different chains specializing in different use cases, how do EVMs come into play, and how does this impact overall user experience.

Then we're going to be talking about why interoperability is important.

Why is it necessary today more than ever to build interoperability standards to allow these smart contracts and applications to talk to each other.

We're going to see the consequences of an ever increasing number of chains, layer 2's included.

And then we're going to do this deep dive into the IBC protocol, explaining how it works, and also talking about, of course, EVMOS and how we take interoperability to the next frontier, and how do we enable smart contract interoperability through IVC to connect not only to smart contracts but also to other chains in the Cosmos ecosystem and the EVM world.

So you guys are familiar with the Cosmos ecosystem in general, more or less?

Nowadays, back in the 2015 era and 2017 era, where all these ICOs started booming, The only choices for developing a new platform or a new project were either forking Bitcoin in the early days, like for example, C-cash, and on top of that adding privacy on top, Litecoin, etc.

And through Ethereum, people now started building smart contracts on top of the same platform, which was great.

You can build different applications, different use cases just by writing your smart contracts, and this was like a shared stack until in

Cosmos announced its vision for an interoperable world of smart contracts, where the premise here was there should be applications that are not only able to live on a shared virtual machine, but should also have full ownership and sovereignty over the entire stack.

That means that using an SDK or a programming framework like the Cosmos SDK in this case, you will be able to write your own application specific blockchains, or app chains, as they're called, and interoperate with other applications through this interoperability protocol called IVC.

So instead of going through a horizontal scaling, we shift the model to vertical scaling, where you handle more TPS, you handle more validators or nodes that are participating in consensus, you're just scaling horizontally via an Interoperability Protocol.

And this is key to understand that on Ethereum, we find all these smart contracts that are able to share code with each other.

You're able to call other smart contracts and components on top of each other.

The money Legos, the DeFi Legos as we know them.

But with interpretability, that's also an amazing case.

So once we started seeing an ever increasing number of applications, layer 2s, specialized for different use cases, we're starting to have these user experience problems, as we see here.

So we have, for example, Aave or Curve that are now deploying to multiple environments, multiple EVM chains.

And that's also affecting the overall user experience.

I guess another check-in, do you guys actually use all of these chains when you're using Curve or Aave?

Is this something that you're excited about?

Okay, so you said you care because there's different features or functionalities and you mentioned liquidity, is that the only thing?

We talk about the EVM compatibility between those chains, so that's easier to deploy the same application or same DAP on multiple chains.

Okay, well, it's good to know, because our goal is to basically remove that selection for the end user, so overall UX is becoming more and more important, And so we're pretty aware of that.

Yeah, so this is a Wait, there's another 1?

what chain you're on would become relatively Sorry,

of the day what chain you're on would be relatively transparent?

I mean, ideally, as a user, you just show your intent of what you want to do, or the program, and you're not really concerned with the network.

But you have to have some entrance point.

And then what happens on the background, depending on which chain it is on, is really not of your concern, actually.

That's why I say it's like the selection, the dropdown, shouldn't be there.

I mean, what you see here is, in the Cosmos ecosystem, we have so many chains popping up because they are optimizing for 1 specific application right there like application specific blockchains that allow for sovereignty.

They have their own token, their own validator set, their own community as well.

You could see them as all individual DAOs.

It's like the Cosmos ecosystem is trying to basically build this scalable way of new chains that are opting into connections with other chains, but they could, you know, it has like very good security implications, you know, if 1 chain dies or something goes wrong, it actually doesn't really affect other chains.

And so in the Cosmos ecosystem, we're really trying to tackle the idea of scalability in a very different way, whereas on Ethereum it seems like everybody's kind of, you know, building on Ethereum until it becomes expensive or it's not really scalable and that's how we're coming basically from 2 different sides and trying to connect them.

Basically the layer 2 vision for Ethereum is what Cosmos initially envisioned as like okay you have application specific blockchains that communicate with each other and now you have layer 2s that are specializing in privacy, you have rollups that implement like optimistic rollups, CK rollups, and then Maybe there might be some layer 2s that are only specializing in 1 specific category of applications, say DeFi or NFTs or ReFi or DAO tooling.

For example, Nielsen Chain is really big on DAO tooling and DAO frameworks.

So there is going to be a transition into going to the niche of your users and targeting that niche and having interoperability come into play.

And of course, there is scalability concerns, and of course, composability concerns.

Because now the LEGOs that were previously available to you on Ethereum, like all these smart contracts, amazing smart contracts that now are very expensive to run, are not available to you on your EVM.

If you want to build an amazing application that requires chain link, but chain link is not available on your EVM, now you can't build a lot of the DeFi primitives, like lending markets.

So how do you interact with other chains that do have these Oracle services in order to compose and build on top of that?

So We saw that onboarding users is really hard.

Users don't need to choose which platform they're in, what wallet they're signing, there are different standards for signatures.

So ideally, these should all be abstracted and basically, as Daniel mentioned, based on the intent, the application should be the 1 directing to the corresponding chain or to corresponding smart contract on different EVMs.

So this is just an example because like I mentioned you can come into the cosmos ecosystem or Ethereum from like different angles right either friend tells you sends you some some ETH or or you're in some testnet or a developer like there's just so many multiple angles and communities to tap into and so onboarding users is really hard depending on you know the the previous knowledge that they have and maybe also if they already own some crypto in a different ecosystem, or just are trying to on-ramp from fiat.

So, that's a problem that we're really aware of in the Cosmos ecosystem and you know we're trying to we have a I guess also our front end or our application where we want to unify this onboarding experience and help users.

And we really understand that building assistants or co-pilots to lead users through that experience is quite important.

And the whole goal is basically we want people to onboard just once to crypto in general or to yeah to crypto in general basically instead of having to force people to download multiple wallets or have this notion of like 10 different accounts depending on which chain you're on?

So basically the premise is, okay, I want to onboard to Evmos, I want to use a smart contract application on Evmos, I have tokens somewhere else.

How does the frontend know where those tokens are located and through which route to route them through EVMOS in order to start using that decentralized application.

Then once those tokens are in EVMOS, what happens with the EVMOS tokens that you need to pay for transaction fees.

So in the user journey towards onboarding, specifically from other chains, you need to take into account different routing mechanisms, different costs associated for the transaction phase first in the Ethereum world, like for example if you're bridging directly from Ethereum, but then there's the other concern that maybe EVMOS is not your last stop.

Maybe it's like you're routing tokens through Evmos to the rest of like Cosmos ecosystem chains.

Do you need to send another transaction, like bridge to Evmos, then another transaction to somewhere else?

That's a painful user experience and that's why we're trying to work with these core technologies around interoperability that are going to be 100x the overall user experience.

Not only for us, but in general for the entire ecosystem.

And our hope is that in 2 to 5 years, everyone will start using these smart abstractions for transaction fees, for routing through the ecosystem based on the shortest path or on the cheapest path to a destination on another counterparty chain.

This is our first attempt to also improve the disk availability.

So before you onboard, you need to have an intent.

OK, what am I going to do on FMOS right now?

And for that, discovering what the possibilities are is really important.

And on FMOS, we're trying to push for our Dapp Store, which is showcasing, in the same way that you might experience with your Google Play or App Store on your phone, showcase the different developers, the latest news, leaderboards in different categories for DeFi, Gus Gustlers, what are the most use or more popular smart contracts being interacted with.

We're also showcasing different content that is going to be on announcements that are going to be created by these different teams.

And this is our first push to declare first the intent, and then through the onboarding experience that we just mentioned attract more users to the EVMOS ecosystem.

Yeah I think the idea of this also is you know if ecosystem dApps that you see listed here shouldn't be just deployed on the EVMOS chain.

You could also think like this is the Ethereum dApp store or whatever but the point is you don't really know where these applications are actually hosting their code.

The second big topic that we are working on, besides onboarding new users into our ecosystem, is changing the mindset from going multi-chain, like deploying different instances in different EVM chains, to just being cross-chain, deploying once and having these interoperability obstructions to work everything for you and not having to suffer this user experience of going through the drop-down and interacting with multiple blockchains that might be helpful for overall user experience.

Today, you can interact with Aave on different EVMs, different Layer 2s, Mainnet, on Ethereum, etc.

But Aave not only has 1 single version deployed, it has multiple versions.

What was being described here before is like, OK, you have access to different functionalities, but what happens with the engineering team that needs to maintain and keep track of all these new functionalities?

They need to have separate instances with that specific functionality on different chains.

And moreover, not only for the engineering team that needs to maintain more instances and keep track of any breaking changes, any upgrades specifically on EVM chains that are not using Nakamoto consensus but are using BFT consensus, They need to keep track of that.

And also for the community teams, what's going on in terms of governance?

How our community, like our AVE community, is getting involved in all these different instances and all these different chains?

Are they able to participate in governance?

You have Snapshot that is deployed on Ethereum for voting.

How do you manage snapshot across different instances?

Do you need to submit a different integration for every single EVM chain?

So those are the questions that, today, a developer needs to ask themselves if they want to go with a multi-chain strategy.

But the ideal case scenario, and we're talking about 2, 5 years again from now, is you only have 1 instance, 1 instance that your team needs to deploy, and you can access it from every single EVM chain, every single Cosmos chain, every single smart contract, not only Solidity or like EVM based smart contracts, but also Wasm smart contracts, JavaScript smart contracts, Solana smart contracts, And you can, through the interoperability, compose and build on top of it.

So this is the vision, the longer-term vision that we're trying to aim for.

It's like deploy once, connect with everything.

And this is why it's so game-changing and why it's so important, the interoperability, that besides all the user experience, it also brings huge benefits for the entire development teams.

You don't need to hire 5 community managers, 1 for each ecosystem.

So the idea is when you just deploy once, right, or when you are trying to, actually when you're trying to create a new application and trying to build a new application, currently in the Cosmos ecosystem, 1 way is to do it, you just launch your own chain, have some custom core protocol functionality, maybe your application is baked into the protocol or you're running a VM and building smart contracts.

But the idea is, it comes with a bunch of problems, right?

So Fede was mentioning earlier, you actually, every time you build a new chain, you'd have to rebuild certain, you know, basic applications to have a rich DeFi ecosystem or any other, just DeFi is the most prominent.

And so, if you have this notion of being able to access data or I guess liquidity on other chains, you don't really have to think about and worry about bootstrapping these basic building blocks.

So, basically we're rethinking the way that we also measure, I guess, the success or the activity on a chain.

A lot of chains are thinking about okay how do we optimize TVL or just yeah use that as the main measurement of success and maybe also possible revenue methods but for us it's actually rethinking this and we want to make sure that people just think about access, right?

You don't need to build a protocol like always launch your own token and then optimize for TVL.

It's rather how do you reuse components or liquidity that other teams already have Builds up basically so it's kind of like if you think about it There's every chain could be like a different API or different service that you can have access to.

And I think the UX point, I mean we mentioned it quite often already, 1 big idea is that you don't need to be concerned with paying transaction fees and different tokens.

You can just onboard once to your 1 favorite token, maybe EVMOS, ETH, whatever, but you just connect it once and then you're paying transaction fees for services, even if they're on other chains, with that token.

And that provides just a better user experience.

The access to liquidity part that Daniel just mentioned is very important.

Right now, everyone knows you don't have wrapped ETH.

First, you don't just have Ethereum, you have wrapped ETH, staked ETH, and different denominations of liquid staking Ethereum.

So in that sense, the original token, the ETH token, is now fragmented across different denominations only on Ethereum.

But what happens then when you bridge them over somewhere else, and then it fragments the single token even more.

So now you have this initial pool of tokens, the ETH token, that is scattered around different denominations everywhere in the ecosystem.

You can't just build pools that have like the initial value of the tokens, but you need to work with what you have on your local chain.

And that's the concept of total value log, the TVL, that a lot of chains are trying to optimize for.

And our shift of paradigm at Evamos is not how can you build more TVL natively on the chain, but how can you access that liquidity that is scattered everywhere?

So how do you enable a smart contract that lives on a chain that doesn't have like these DeFi Legos that I mentioned that you need in order to build your smart contract and doesn't have deep liquidity for your application to exist?

And this shift of paradigm allows us to rethink how these smart contracts should be interacting not only with other smart contracts in other chains, but with application-specific blockchains like Osmosis, which is the main DEX app chain in the Cosmos ecosystem, to access that liquidity via interoperability, getting those tokens back, and then using them for whatever use case they might need.

So, Access to interoperability is a keyword, not total value locked on a single chain.

Let's expand from the constraints of the single EVM and look beyond that into what's over there, scattered and fragmented in the rest of the ecosystem.

And so that brings us to our next topic, which is the inter-blockchain communication protocol that I was allowed to be part of and built with the rest of the interchain team.

So the interblockchain communication protocol, I'm going to go explain what it is, but basically you have, in this case, 2 chains with their own validator sets, around

validators, coming to consensus and validating blocks.

So the main thing is like, okay, Bitcoin solves the double spending problems.

Right now when you're thinking about cross-chain, how do you solve the double spending problem but when you transfer over to another chain?

And for that you need to be able to validate the state transitions or the like transactions moreover on 1 chain on another chain.

And for this, it's critical the role of the light clients.

So light client proves there's an actor in between that I'm going to explain right now that runs light clients of both chains.

And he's able to verify the state transitions on chain A and chain B and constantly update the latest state.

For example, updating the state of the chain A for chain B and vice versa.

And with that you're able to verify that a token has been locked, or the token has been released, a token has been minted, or a token has been burned.

The concept of IVC first was meant to be defined in the same way as the Internet protocols with different layers.

So you have the proofs that are like Merkle proofs to be able to verify the state transition.

Then on top of that, you have the like lines.

The like lines are, as I mentioned, the key components to be able to verify state transitions between the different chains.

Here the relayer in between is able to run the light clients for both chains.

So this is like the bottom layer clients, IVC clients and the light clients for the different chains.

And on top of that you have the connection.

So connecting 1 chain to another is the next primitive.

And then on top of that you have channels.

You had the connection between 1 chain and another and then I'm connecting for example the transfer logic like the state transition for balances.

So that's that will be for example the okay I want to transfer some tokens from my chain, chain A to chain B, or EVMOS to osmosis.

I'm updating my balance on EVMOS, reducing it.

That Merkle proof is submitted via the relayer.

The balance is updated on the chain, on osmosis, on the receiving chain.

You get an acknowledgement back that the transaction was successful, and then that token that was held in escrow is then burned.

And that's how it finalizes the state transition.

I guess for the channels, I think, Like right now, basically you set up a channel for different packet types, right?

And the 1 that's mostly used is the transfer.

But actually, IBC is data agnostic, right?

So you could send any kind of data that's encoded.

Yeah, and on top of that you have the application layer.

So, after you set up, you have the proofs, like lines, connections between 2 different channels between 2 different smart contracts or modules in the Cosmos world that are able to decode and encode data, the packet data that is sent over in this envelope, this packet, And then you have the application that handles that specific data that has been decoded once it's received.

So, It's not very clear here, but the cross-chain user experience, you have 2 models for cross-chain user experience.

1 is using an application, an IVC application that is using a specific channel.

For example, I want to send tokens from my chain to EVMOS to Osmosis.

And what I do use is here's the interchain agent, talks to the IVC transfer module with an IVC transaction that declares an instruction to transfer.

And that works for transfers, like balances that need to be updated, But what happens with other transaction types, like staking, if you want to vote on governance for another chain, or if you want to, what's this?

So like other whatever modules you might want to build.

And for that cross-chain user experience, going back to the same problem, like how do we remove this need of having to switch different networks, is just having 1 single account on FMOS that now, through smart contracts or on your behalf, is able to send instructions everywhere to submit different transactions.

So you remove this dropdown completely and just use EVMOS, and you're able to send instructions for all the different chains that you have tokens around, for all your portfolio tokens.

And then you are able to send IVC transactions, for example the transfers, and non-IVC transactions that are like local to that specific chain, for example, staking, or sending a governance boat, or sending a CDP action.

So those are the 2 different UX models that we have right now.

1 is just using an IVC application, which is perfect specifically for the use cases of just using it once.

But if you want to manage something on the medium term, you can use interchain accounts, which will allow you to manage your portfolio without having to leave the receiving chain.

I wanted to send a transfer over, transfer to the receiving chain on, for example, osmosis, evamos, osmosis.

And you can have that token sent back to you, or it can be kept here.

Let me finish this, and I'll give you the work.

And for more management, or management over your portfolio, you can just send the instruction to the receiving chain for all these different interactions.

The zone, that's like a standalone blockchain, right?

And the interchain agent, is it a part of the full

node implementation of that original blockchain?

So the Interchain agent here, it was defined as such because it's either a user, like an EOA account, externally owned account, like a user or a smart contract.

So imagine this is a user, just like a person here, interacting with the IVC module on sort A.

But it can also be a smart contract, and a user here interacting with that smart contract or series of smart contracts that are using the IVC module transferring to the corresponding chain.

It's already implemented on the on Cosmos.

So just so it's on record he's asking if IBC has to be implemented on the zone, right?

implementation go into, like, do I have to implement it in

Yeah, so you're asking where does IBC kind of, where is it implemented?

But it's part of the node, basically, the full node.

We're going to talk a bit later, how can you leverage IVC being a smart contract Solidity developer?

So you don't have to implement all this logic, This is already extracted for this, and you just use Solidity interface with the AVIs.

So Evmos, working on these 3 main items, is taking interoperability to the next frontier.

Working on these different use cases, particularly around onboarding UX and access to liquidity.

We're going to be talking a little bit about that now.

So for I guess I mean we mentioned fMOS quite a lot for those who don't know we originally created Ethermint which is the EVM library which has been used by not just ourselves, but also other chains to actually launch their EVM chain, especially in the Cosmos ecosystem.

And we only see actually more and more EVM chains emerging.

So that's kind of our thesis why this interoperability is super important and also setting the standards of how these chains will be able to interact with each other.

And it's really interesting to be here at, you know, ETH conferences.

Last week we went to Gateway to see how different the communities are.

So for us it's quite nice to bring these worlds together.

And we chose to build the EVM implementation or use an EVM implementation in the Cosmos ecosystem to combine both of the best parts of those 2 worlds.

So composability through smart contracts from the EVM, but then things like sovereignty or, you know, the whole scalability of the Internet of blockchains in the cosmos ecosystem.

Okay it's a bit hard to see but basically the EVM extensions are the functionality that we're building to allow for interoperability from the EVM.

And without these EVM extensions, you have, you know, maybe your smart contract deployed on the EVM, but they're pretty isolated.

You don't really have access to data outside or liquidity outside of the EVM smart contracts, as Fede mentioned.

You can talk to other smart contracts or EOAs to those, but they're pretty contained in the EVM.

See all Parallel Polis transcripts on Youtube

Crossing the Interoperability Bridge: A Deep Dive into Building Interoperable dApps with IBC