Expanding the Capabilities of the Ethereum Virtual Machine

ETHCC 6 · July 2023 · 29:06

Federico Kunze Küllmer explains how Ethermint combines EVM functionality with Cosmos SDK interoperability modules, including IBC. The speaker considers applications that operate across multiple blockchains.

Speakers

Topics

From ETHCC 6, hosted by Ethereum France.

Transcript

[Music] foreign [Music] hope everyone is restored after the first night my name is Federico I'm the founder and CEO of Atmos of Atmos for the ones don't know us is a interoperable evm we are based on the cosmos ecosystem but we're expanding the evm into the rest of the evm ecosystem enabling full interoperability between smart contracts and today I'm going to talk about how we are expanding the capabilities of the evm with our interoperability technology

oh yeah I need to train I don't know perfect so the AVM um so the evm's standard is what right now supports all the smart contract it's a powerful a piece of the stock of the ethereum network that allows the smart contracts to be compiled and then the buy code translated into the virtual machine and executed and executed State transitions but the evm more broadly as a narrative has been increasingly growing and today we can see that most of the tvl in the entire blockchain ecosystem is located in evm Chains making it very compelling

for new developments new chains to be built using this piece of the stock and so today you can see here there are more than 150 um evm change today in production that are accumulating most of the tvl like these from July 1st ethereum 62 percent um Tron 13 BSC seven percent and so most of the tvl lives in these evm chains today even though there's different ecosystems that are trying to tackle different VMS or different protocols application specific blockchain

narratives like Cosmos Etc but with this evm chains expansion also comes at a trade-off which is user experience on developer experience um you can see here how cumbersome it is to constantly go to your wallet and search networks um depending on where the application is located right now all the different teams that are deploying to these different evm chains have to manage the entire ecosystem they need to do the redeployments they need to manage infrastructure and more importantly operationally speaking they also need to manage the communities and for for a user perspective even though you can use the same wallet

on the same address on these different evm chains you still need to go and switch your network which is not the best ux and so right now ethereum has this Narrative of migrating to l2s for scalability so you have the EVMS like the vertical stock where it supports all the smart contracts and for scalability purposes they are using layer twos that are settling into ethereum so ethereum is a settlement layer um but there's this major issues that is going on right now of like us these uh layer tooth grow over time there also needs to be some sort of like interoperability protocol um that can allow them to compose and to

build on top of each other's uh defy applications so for example what happens when you have certain components that are useful for your application that are not on your layer too then what you need to do is like go on look on ethereum go and look on other evm chains for these same applications that you already have on ethereum but are preventively expensive for you to run or for your users so there's all these um narrative going on and even metamask on an Institutional account was saying that one of the major limitations of the evm at the moment is that in terms of interoperability there's no clear

standard for interoperability between smart contracts and thus the all the advances that all the other ecosystems are doing at the moment poses a threat in terms of like user experience Narada building composability Etc that ethereum today doesn't have so that's why I want to expand on this topic today on how can we achieve evm interoperability well at the same time retaining the same grade properties that the evm has today so taking a step back what do we need interoperability we talk a little bit about the D5 Lego so like these pieces that allow you to compose

smart contracts built on top of each other for example if you have a landing Market you of course need an oracle for the different pricing so ethereum allows you to do that today very effectively but again it has some limitations in terms of transaction fees Network utilization security Etc interoperability is also very very important for accessing liquidity right now on some people's some people might disagree with this but right now the liquidity even though it's a mostly on the evm as you saw before with 155 evm chains in production these liquidity is fragmented so you have the

ethereum token like The Ether or the usdc that is correctly fragmented and you have like rap versions or like Bridge versions or another EVMS so these liquidity even though it's been minted on the same protocol it's not accessible to the applications that are deployed on these other evm chains for example cello that is migrating to the evm might require additional sources of liquidity that are not available on cello and thus constraining the user experience constraining the developers in terms of their requirements specifically on D5 applications that require these deep liquidy and again user experience having to manage all these

accounts even though you can use the same address is painful user experience and so interoperability is relevant extremely relevant for these three reasons so going to like what's a wish list when we are talking about evm interoperability so of course accessing the state that means reading and writing on the AVM virtual machine so you have like the read which involves queries querying the state of different smart contracts querying different states of um like generally the protocol the core protocol and then writing transactions so how are you able to compose how do

you able to call different smart contracts and this involves not only smart contracts that are evm compatible but also layer ones and options that are for example on Cosmos all your other layer 2 Chains and other VMS this involves Solana VM cosmosum which is like the awesome standard on on um on Cosmos you also have you can also have interoperability with different smart contracts that are on Avalanche Etc so this is very important for achieving these goals of interoperability so on evmos we're trying to pave the way for these evm interoperability

while retaining the basic properties on on the benefits that the evm offers today how are we doing that by changing these multi-chain strategy which is like deploying the same instance everywhere into having like a crushing narrative where you only need to deploy once and then manage and access all the liquidity all the compost ability like this D5 Lego that I was mentioning today on with while retaining the best user experience that uh you can today so evmos allows you to have the programmability programmability and composability of the AVM while retaining the sovereignty uninterpretability of

the cosmos ecosystem it's what we call a programmable interoperability um so how are we doing this how are we achieving evm interoperability is through the IVC protocol IVC stands for inter blockchain communication protocol and it's a canonical protocol that is widely available in the cosmos ecosystem that I was lucky to be part on a member of contributing team I shift the IVC core protocol Primitives and then I was part of the team that shipped the IVC protocol in production in 2020.

so using dark knowledge and using the knowledge that we built on the evm we're now able to offer different scalability solutions horizontal scalabilities while retaining these probabilities that I mentioned before so the IVC protocol how it works you basically have two chains a relayer that is running like client verification proofs so you can verify state that it has been executed in Two Chains so here you have the evaluator said the two different chains and in the middle you have a relayer that is verifying this I have a chart that I will show you afterwards how this works at a technical level for the ones I want to take a picture but going back to the important right the

important thing is like user experience how can we acquire more developers how can we enable new use cases um so IVC applications they usually have like two categories one is for single interactions and another one is for repetitive interactions periodic interactions so IVC applications right now um you can for example execute a cross chain swap like set a set of instructions to a counterparty chain um so for example if you have a you can execute uh swap on osmosis which is like a cross chain deck like interchange decks on the cosmos ecosystem swap that token get the token back and then execute something uh

programmably so you can Define the logic after you see the token I want to do this or that with a token and so you have this compostability aspect that is really relevant then there's these other narrative that is starting to develop now because this is a recent development in the cosmos ecosystem which is interchange accounts so interchange accounts has different um the main difference with the other use cases that I said was a one-off trade execute something that the user has defined uh interesting accounts what it allows you is to perform recurring actions on the counterparty chain and then maybe every now and then transfer back to the original chain so what this allows you is like for example you can

use Atmos to manage liquidity on ethereum so you can like run all your computation on Atmos and uh every now and then just like perform an action on ethereum or perform an action on another chain so this is really relevant for these type of use cases and which will enable again interchange composibility through our IVC interpretability so okay we talk about it the Evian interpretability we talk about why it's important and we talk about how we're using IVC and the different um the two different cases where you have like one-off interactions or like repetitive interactions where are very

frequent how we are enabling that is through our evm extensions so our evm extensions what it what they basically allow is to um technically speaking for the ones that are have deep understanding of the evm it's a stateful pre-compiled contracts so traditionally on ethereum you have if you recover to verify their private keys on the signatures and you have like other elliptic curves etc those are stateless functions that you can interact today on ethereum but what happens when you want to access State when you want to read state or write State on on the core protocol in this case evmos

um on the Avon CVM these evm extensions would allow us is to access those core Cosmos functionality like staking governance IVC you can manage again interchange accounts and you can access all these interoperability functionality through very intuitive solidity Avi interfaces so you don't need to like all these givers that I'm telling you about IVC and how it works you don't need to care about that you have an Avi interface and you can access it and you can interact with it it's audited it's secure it's been bottle tested in the cosmos ecosystem so for developers it's really simple to

interact with these Cosmos primitive so what this allows you is that now you can enable stick file you can build powerful dials that bake into the core Cosmos protocol and you can build like new governance mechanisms you can access IVC you can access liquidity that is not available on evmos but it's available on other chain that has been fragmented and so the evm extensions what it allows you is to have these predefined smart contract address to access different customer functionality and then um one major besides AVM extensions what we're trying to do is okay we talk about

evm interoperability as a broad category interacting with layer ones interacting with Layer Two Sun um smart contracts so what about application specific blockchains sometimes a smart contract today cannot interact natively via IVC so how do we enable application specific blockchain functionality those up chains that have their own business cases have these different transaction mechanisms with solidity and that is what we call today Outpost so these like smart contract interface that allow you to interact with the up chains So today we're uh in the next few months

we're launching two major outposts to uh two major um ecosystem players in the cosmos ecosystem one is stride uh it's a liquid staking uh chain that allows you to stake any token and get a legal stake and derivative for that so how this look likes for the um the users is that instead of having your stride address here you just have enough massages and you can interact directly with metamask opening the same application to 30 million users and even more developers that can compose with such functionality so how this works on a technical level

is that you have um this try chain or the the strut outputs on the atmos chain you can interact with Ledger Kepler which is when a major wallet on on Cosmos metamask and any other evm one you have the predefined address for the stratout Post uh you execute an evm transaction it converts that into something that the IVC understands under the hood on the Chrome protocol I need just sends the instruction to the stride chain on the stride chain what it does is like automatically liquid sticks that uh into atomos through what it's called technically like this IVC middleware and

then you get on the fmos Chain you get your liquid staking token and then is a final introduction that you do is like a two-way interaction and after that you can also Define your custom logic you can define whether or not you want to like use that liquid staking token that you just received on a DEX or you can like Farm it so the it allows you to do all these different interactions today on the um through this outputs model and same with osmosis the same interface only changing the atmos like the application specific address to something that is uh evm compatible so like a hex address or

the atmos formatted address and same you have the Outpost you execute an EV an ethereum transaction it routes in sends instruction to swap a token or to provide liquidity Sensei IVC transaction over to osmosis execute the swab or execute the liquidity provisioning you get the token that you want either the lp token or the token that you wanted to swap sends it back to Atmos and you can do something different based on your programmability on the smart contract so this is a very powerful narrative like today what we're enabling is like liquidity previously was constrained by the AVM so you had

this concept of tvl that I mentioned initially that is like how much liquidity also all there on the all the evm chains individually today with this functionality you can access liquidity that is not available in your chain is what we are calling like total researchable liquidity or Omni liquidity like access all liquidity that is available in the ecosystem on this especially when you're launching a new chain when you're launching a new smart contract it's really crucial because sometimes you don't have that deep liquidity requirements on your native chain with this functionality now you can access it so we talk about writing State we talk

about how you can access evm extensions use IVC to interact with smart to interact with other layered ones on how to interact with via IVC with other application specific blockchains what about reading the state so there's like a powerful um application standard on the customers ecosystem that is called interchange queries it works in the same way as that I was describing before it's like you should find a set of instructions what we want to do on the quantum party chain in this case what you define is a pocket an IVC pocket with a data instructing the the receiving chain to read some part of the state on a

specific smart contract or in a specific part of the state here it's using the bank module that handles the balances but you can literally Define any smart contract data that you want to read on the Avalos chain and in reset State sensing response bug with a proof so that you can actually verify in and then you execute something else so again interchange composibility this Narrative of accessing State either reading or writing on what this enables is for example you need a you need an oracle for your lending Market it's not available on your native chain how can you access an oracle service that is deployed somewhere else on this

for the ones that are involving Business Development here or for the ones that are starting their evm chain here you might have run across that it's extremely expensive to get these deployments on your evm chain so every one of these 150 150 production evm chains has interacted with one of the major players in terms of like these D5 Primitives these D5 components that enable these compost ability on the AVM layer on a single virtual machine but it costs like 1 million per deployment then recurring costs for maintenance so with this you can like

strip all of that you can access liquidity that is not available in your chain you can access services that are not available in your chain so like we're completely Shifting The Narrative from uh paid uh pay to play um to something that is like accessing all that via interoperability like it literally can save millions of dollars in like Integrations so interchange query is what it allows you is to access state that is not available today on the evm but on this being realistic like there are some limitations about IVC we saw last week how the multi-chain hack happened and how vulnerable this

different Bridge architecture are today um the main problems with IVC is that the core Primitives sometimes are not applicable to all transfer protocols sometimes you just need a simple like also have a very rough solution for transferring tokens from one blockchain to another I don't need a huge security mechanisms and that's what ethereum is using today and then for the Pocket Data encoding on the coding so this information needs to be understood on the sending chain on the receiving chain so that they can like understand the instructions execute them and send them back um it's expensive if you're running on IVM chain you don't want to spend most of

your gas on decoding uh like Pocket Data so how do we support uh Avi encoding uh our ROP encoding which is something that ethereum developers can already serious smart contract can already understand it takes longer Innovation Cycles because today the only way for you to build a smart on uh an IVC application interoperable is to build your own chain it's not available for smart contract Developers and so what we're introducing today is like instead of striping these like application layer which is on the top it's what you care right is what you want to achieve by having this interoperability between smart contracts layer ones Etc

but you don't need the channels the connections the clients you want to wrap that around and have it available to you that's a powerful narrative that we're introducing this year which is called Dynamic IVC what dynamic IVC is is a wrapper around all the core Primitives outside of these interoperability protocol so that smart contracts can Define verify and encode their own pocket data so what this allows is like instead of having to wait for the next IVC application um you can Define your own and you can interact not only with evm smart contracts on other chains but you can

build your own interoperability applications using decent interoperability protocol this is the first time that the cosmos ecosystem more broadly is opening its doors of interoperability to Smart contracts so traditionally you have a Pocket Data with all these jigarish sequence Source Port destination Port Source Channel you don't need to understand that the only thing that you care is the data the data you're sending over to the chain and so what we do here is um creating a solidity interface on the Avi so that you can wrap that around send an IVC pocket with a sender you

have the destination that is already defined in the Pocket Data and you just send it to the destination chain it gets handled there by the smart contracts it gets verified the smart contract itself sends the X sends the acknowledgment to the original sender chain and you can handle your own interoperable application on a smart contract this will enable EVMS to connect to each other smart contracts to connect to each other not only evm or solidity based but expanding the limits of the interoperability expanding the capabilities of the evm to possibilities and use cases that we haven't even enabled today so we're really excited to be introducing this if

you have any questions or if you're interested in building with this technology specifically the evm extensions the outposts that are live today Reach Out and so the advantages of the IVC again faster base of the Innovation allows for smart contract interpretability opens new use cases and is cost effective for applications thank you very much and here's some resources we have an academy where we have a few tutorials and guidelines and here's our test net faucet if you want to get started with this interoperability functionality on the evm thank you very much

[Applause] I think we have time for one or two short questions otherwise happy to take them afterwards um thank you very much for how you talk how do you manage the finality because like if you want to call some optimistic holdups or that covered up so like this you have to wait sometimes before you have the the finality yeah so it all depends on the finality uh that it has been implemented on the on the consensus level on the

chain on the destination chain on the sending and destination so on the Customs ecosystem on many other other ecosystem chains they use bft so that means like they have instant finality so you can use just IVC wait for one block gets committed since it's sent over and you don't need to wait for the for the finality but as you said ethereum and other ones are using what's called Nakamoto consensus which mean that you have a probabilistic finality that you need to wait a few blocks or you have to set the parameter for the security um that you want to send and there's some teams already that are working on this um IVC with the non-instant finality for example the polymer team is building

something for ethereum specifically and we're planning to leverage these interoperability functionalities to not only access bft chains but also access Nakamoto consensus change with probabilistic finality okay this will be the last question what's the read latency in between two Cosmos chains sir can you sorry what's the latency how long does it take to read a value from another chain there the the question the it depends um so like for example uh evmos has like four seconds um some of them have sub-second block time on for example Cosmos of six

seconds it's all configurable on the on the Chain so as long as all developers Define like a timeout for how long they need to wait for committing a block but that's again depends on the configuration that's an asynchronous read then not a synchronous read it's not Atomic in the sense of like you need to wait for the acknowledgment to be sent back and then you read the acknowledgment whether or not it's success or or a failure error on the on the destination chain so you need to be able to like lock the lock the tokens for a specific period of time you go receive the acknowledgment and then you like unlock the tokens and continue your your logic but it's not it's not that big of like a like a long

latency it must have it must be less than what you have to wait today on ethereum to like get one block confirmed thanks okay thank you Federico and uh thank you very much [Applause] [Music]