Evmos 🛠 Evmos - The Next Frontier for EVM Development

[Music] [Applause] hey everyone welcome my name is federico conseculmer i'm the co-founder and ceo of atmos which is an evm on cosmos today i'm going to talk about what atmos is and why we think it's the next frontier for evm development um i'm going to start a little bit with what is hapmos and what's its architecture um atmos is a cosmos sdk based chain the cosmos sdk is the framework that cosmos have for creating application specific blockchain the in the case of atmos we have an evm module which is where the car functionality that allows us to run smart contract and allows us to have this evm module talk to ivc thus making smart contracts full interoperable with the rest of the ibc ecosystem and the interchange ecosystem um i'm just going to explain a little bit what the cosmos sck is and how it talks to consensus we have here on the left side we have a tender main core which is the consensus engine that runs bft pvfd proof of stake consensus so how the application communicates with with the consensus engine is through an interface called avci that stands for application blockchain interface um so the application itself handles all the business logic or the all the in this case like the evm logic running smart supporting smart contracts you can also see that we have a staking module uh web 3 which is in this case like the json rpc to fully support all the ethereum tooling we also have like a governance module so like this is all handled on the cosmos sdk in all these modules that sit on top of this framework um and then the application itself sends the updates on and communicates with the consensus so that the transactions can be verified on well the the where the gossip of the different messages and transaction occurs between like the different validers and node operators so [Music] just to quickly summarize atmos is a cosmos based chain that has an evm module that fully supports evm on smart contract interpretability through ivc um one of the main components besides the evm is the ivc component we've now seen a lot of chains sparkling in the ecosystem but and you can see here how the different connections between these ivc ecosystem can be handled right now one of the most important applications that sits on top of ibc is like the um ics-20 which stands for the fungible token transfers between different chains this is different than creating a bridge architecture because it's fully trustless and uh fully trustless and yeah different chains can communicate with each other by running like light clients of all the different chains and that's verifying the microproofs against each other [Music] we see we think that atmos is going to be the main point of entry for all the developer adoption in the evm ecosystem because if we start thinking about like interoperability there are three major interoperability clusters right now in the blockchain ecosystem the first of them being the evm ecosystem with all the evm chains that are in avalanche we have ethereum of course and then we have like other evm siloed chains in polygon uh gnosis chain etc then we have on the other interpretability cluster which is cosmos with the ivc protocol and then we have polkadot with crosstrain message passing and through mmos we'll be finally able to connect all these different clusters of interoperability that are right now in the blockchain ecosystem that previously wouldn't be able to to connect before um they were like evm bridges but we are the fully we are fully interoperable evm chain running on cosmos so we can send transactions to other evm chains we can send transactions um to other cosmos chains on through moonbeam we can also talk to other chains in the pocket cluster of interoperability atmos is not only going to be an evm application specific blockchain but it's also meant to be an evm hub in the cosmos ecosystem we define hubs as the chains that can create that other chains can derive security from unless we can create an like a healthy ecosystem of evm chains where atomos seats on top on other chains can also talk to through ivc by creating like for example cross chain delegate calls or cross chain contract and at the end of share security model we allow all the other chains being evm chains or non-vm chains to derive security directly from fmos by uh sending validator said updates to the counterparty chains in this case like the consumer or child chains that will be able to share the same security that the ms core valid error set provides now i'm going to explain a little bit about the talking model and why we're different than any other evm chain you've seen before so back in the back last year when there was this whole debate during the london hard fork about uh miners versus developers trying to push for or against the eip1559 option there was this major like push from the developers to try to increase the user experience because you are by basically creating ether as a base fee token model of the entire ethereum ecosystem whereas previously before the user experience for the user was that when there was a sudden increase in the demand for uh for block space you have to wait for additional confirmations or you have to resend the same transaction with a higher gas price so by creating eip 1559 you have like a like a fee market where you can have like a more predictable um fee for your transactions and that's like improving the user experience for for all the users that are using um ethereum but there was like this huge misconception from the miners like how they saw the developers on the power they had in the ethereum ecosystem but developers core developers in this case are only one part of the entire community on ethereum so you have like all the holders the miners the developers but you also have the application developers uh that deploy their adapts in uh to ethereum and you also have the d5 users that are interacting with these applications so before ep 1559 there was uh the fees that went directly to the miners and you had like the block rewards that also went to the miners when erp 1559 was introduced the base fee was burned on the tip which was a priority tip to include your transaction faster was allocated to the miners but of course the miners weren't happy when they were take like some portion of their fees were taken from them and burned um so they went against the developers so there was like this huge drama last year of adoption or not adoption adopting erp 1559 but as i said here developers are only one part of the ethereum ecosystem so that's why atmos decided to create long-term sustain growth of the protocol by aligning all the different actors in the ecosystem developers um validators in this case because atmos is proof of stake and then we have like the decentralized application developers and we also have like the uh stakers on decentralized application users um we are doing this by introducing the first dob store so the dubster is a decentralized marketplace for dubstro developers and users where as opposed to eip1559 that is burning the base fee we're splitting the base fee between the miners and the developers that means if your application is successful on fmos you will share 50 of the transaction fees for all the transactions that interact with your protocol this is a major change because we're finally incentivizing all the developers to align in the long term with a protocol a layer one and we're turning the protocol itself to also be a layer one that is focused on consumers that are using the applications as opposed to focuses entire focusing entirely on developer experience so we are trying to incentivize the developers on all the users that are in the protocol so the other side now we i explained the developer side of the app store marketplace um and we also have like the usage incentives how traditional traditionally developers developer incentives and user incentives have been done through different d5 programs or defined incentive program or liquidity programs where different foundations put like millions of dollars for users to provide liquidity on different applications but the main limitation is these are not sustainable in the long run are usually like selected applications which are sometimes not transparent in the decision process of which are which is actually the criteria for these applications to belong in this list of defy incentives um and the main problem as well is that it's not community owned so the community cannot vote on which are the incentives on for how long or which are the applications that are going to be allocated these uh user incentives on the main problem as well that we've seen in the d5 incentive programs is that the tvl doesn't really reflect the traction of the protocol or the users that you're getting so tvo doesn't mean that you have more users um that's why instead of creating this unilateral d5 incentive program at most the evm's token model is allocated a percentage of all the tokens that are going to be minted to allocate them to user incentives what does this mean that the community can vote for which are going to be the projects on the smart contracts that are going to be incentivizing uh they're going to be incentivized and what do i mean by incentivized here we're taking the same approach that you can find on all the defy apps that you can ha you can have a lp pool incentives or all p incentives like you can find on osmosis and other amms um we're doing the same for smart contracts so i i'm going to explain now the workflow uh of how developers can register their contracts for their users to get all these usage incentives so any developer or user or member of the community can't register an incentive proposal via governance so for example i'm gonna allocate five percent of all the newly minted atmos tokens um from these 25 percent that i mentioned before to my contract for that is going to be distributed every week for a duration of six months once the proposal pre-order passes and this proposal is approved every transaction that targets this smart contract will start aggregating the gas spent in these gas pools so as a user you you'll have like a share of the total amount of gas spent and then you're gonna get pro rada the gas that you spend from these five percent of newly minted atmos so all that your users are gonna get um basically like it's a deferred gas rebate that can actually be uh larger potentially than the um than the amount of gas that you spend so you're basically incentivizing your users to spend more um more transaction fees and and interact with your contract so this is really important like creating on incentivizing this two side of the marketplace because like developers can propose user incentives to promote the growth of their decentralized applications but then these incentives as well drive new users and reward them with more mmos tokens where these users that receive all these rewards can spend these fmos tokens on the decentralized applications on different projects and services that atmos provides and through the dapster mechanism the developers will get 50 of these transaction fees um from all the contracts that are incentivizes from all these contracts that they're already deploying so you're getting 50 of the transaction fee for your project and you're also incentivizing you're using your users to use your application so this is creating a positive reinforcement cycle where like new users attract um like spend more transaction fees and then you have like all the incentives that are promoting more growth so it's like a positive reinforcement cycle to promote the long-term alignment of the users and developers with the ecosystem so the most token model is basically trying to align all these incentives with all the different users that we can find in our ecosystem and on the evm ecosystem so we have like the holders that can stake rlp their tokens um the d5 users will be provided uh rewards through these usage incentives decentralized application developers will have this dubster mechanism where they can get as i mentioned 50 of the transaction fee and this can actually go up if voted by governance because it's a fully configurable parameter whereas core developers grants on community pool treasury that can allocate additional sources of funding to booster the adoption and boost the development of the core protocol and then for the validators they will still have 50 of the transaction fees for all the transactions that target the evm and they also have like the block rewards from the validation services that they provide now i'm going to talk a little bit about liquid staking this is a topic that is very interesting and what's happening right now in cosmos so liquid sticking for context uh staking itself initially in 2019 was introduced by cosmos as like the first d5 use cases the the first d5 use case in in the entire cosmos ecosystem because ivc was not live yet um so when we think about liquid staking in the concept in the context of evm we can think about the lightest architecture whether you can have like um the leader staking contracts that they allocate the eth directly to the ethereum deposit contract for the b con the the beacon chain um so the user when they deposit the their ethereum they get like staking eth in exchange but the main limitation in cosmos as well is uh the liquid staking implementation is not a smart contract so that's restricting all the um the smart contracts which are also accounts from actually sticking so for evans taking b2 we're doing something completely new as i mentioned b1 was just a cosmos delegated proof of stake mechanism but with liquor staking we want users on contract that can stake different atmos tokens so users can uh through kepler or metamask can delegate their tokens to the different validers but we want also smart contracts to be able to create different uh defi applications that are targeting specifically staking so that we can have a more secure validator set providing security for all these different chains in the entire interchange ecosystem um i'm going to elaborate a little bit more when i talk about the different use cases that atmos is introducing that are super novel in this in this sense of staking and slashing um but yeah i'm gonna continue now with how we're making erc20 tokens fully interoperable so when we go back into the architecture we find that the cosmos sake has different modules these modules are can talk to each other but the main restriction with this architecture right now is that in our case the evm is completely isolated from talking to these other modules so what we introduce is like a post-transaction execution logic that allows custom logic for um how to execute different behavior after an ethereum transaction is processed in our case we're allowing ethereum erc20s to be fully interoperable with the entire interchain ecosystem how are we doing that by creating like some sort of token pair where you are mapping an erc20 smart contract with a cosmos denomination this is all voted through governance so if you have like 100 ivc voucher atoms um you can both through governance on what is the canonical representation of the atom in the evm so basically here what we're creating is through a governance proposal the community votes on what's the canonical implementation of an erc20 and then you can after that's approved you can start converting uh from cosmos formatted coins to erc20 tokens in the evm that allows all the erc20s that are going to come from all these interchange clusters from the polkadot ecosystem on the evm to be fully interoperable with the rest of the interchange ecosystem via ibc this is going to be possible by by doing a manual access so like the user needs to send a transaction to manually convert these tokens but in the future we're planning on introducing additional mechanisms so that smart contract can also convert this token natively on send ivc tokens uh sorry erc20 tokens to the rest of the interchange ecosystem but just send by just sending a transaction to a contract that talks to the ivc module so i'm going to talk about now a little bit of development on core development i'm going to dive a little bit deeper on what's the logic for evm hooks the evm hooks is what i just explained that allows erc20s to be converted to ivc tokens so we're we're introducing this so that the evm module can basically extend the transaction processing logic so instead of just targeting the evm on the state machine and the like the transaction is process and in the evm we also want to execute custom logic so that the uh evm can execute additional logic with the staking module with the ibc module with the governance module and thus we can create novel use cases that weren't possible before because of the modularity of the sdk of the cosmos sdk so how this works at a high level [Music] we are defining a log signature that is submitted by a smart contract so you have an event that is submitted once a transaction is processed and then the post transaction logic this evm hook for the events are recognizing these logs according to what's the contract that you're targeting in particular and then it executes some custom logic so you can execute native calls on cosmos so i have a small screenshot here of what's a interface for executing push like this evm logic where you have the ethereum message and you also have the receipts and they receive from the transaction once the transaction is successful on the avm you can execute some custom logic on the cosmos side to execute these native calls on here on the bottom this is a simple erc20 logic that we're using for the erc20 module that is executing basically a transfer from um [Music] yeah like converting a like or transferring a token to another chain or to another recipient on the cosmos side so you can actually emit here at the bottom like a transfer event on that event is picked up in the cosmos native module and then you can execute some custom behavior according to what's the contract that is actually executing these event signature now i'm going to talk a little bit about some example projects that i'm particularly very excited about uh in the that can benefit from these evm hooks and also like all this smart contract interpretability the atmos will provide in in the future so the main use case and now i'm going back to liquid staking on how staking can be actually improved is creating sort of like a validator portfolio so right now like the user goes to like a block explorer looks in the balance set and they usually check okay what's a voting power what's a cumulative share and then once you delegate your tokens to a validator usually they to stick their tokens with the validators that are higher in the rank because they are providing them more rewards you can actually with the evm on creating a like staking contract you can actually create a defy validator portfolio where you're you're talking to a contract and the contract is actually sticking those tokens to you and then actually like like spreading the about like the tokens across the valley they are said depending on your preferences and then automating automatically um distributing or redistributing all these rewards to you or to the same validator set uh or to a completely different one so you can al also create like different validator indexes um sort of like maybe you can create like oh what are the batteries that are carbon neutral for example or that are um like located across the globe globe so you can actually boost the decentralization of the evaluator set across the different world inc across the world in case there's there's an outrage um and finally one really particular interesting use case that we're talking internally in the team that can also be possible with the talk like talking smart contracts with the core evm is quitting staking collateralized loans so instead of providing collateral for a lending platform you can actually when you interact with this lending platform instead of providing the assets you can you can tell them okay i'm givi i'm gonna give you an approval to slash my already delegated tokens so that in case you liquidated me you slash my tokens instead of or like you collect my tokens from the that were already um that were already um the stake so you can actually like migrate those tokens that were already delegated or you can for example slash those tokens that are delegated so this is creating not a um serial collateral um d5 platform but you're creating some sort of um [Music] allowance for the default application to actually create these additional functionality for landing platforms um and for the evm you can create an evm ecosystem index so for example you can create like a portfolio of different ivc coins how you manage them so this can be possible for example like somalia somalia can um like it's usually [Music] now only targeting like the evm as a co-processor but you can also create like indexes and different portfolio management strategies to how better allocate your portfolio in the different interchange ecosystem by creating strategies on smart contracts that they can that can eventually talk to every specific chain so that's one example of like how you can create smart contracts that are targeting the entire ivc cosmos uh ecosystem we're also currently talking with the stargaze team on how to create for example cross-chain nfds that are possible to be treated between like the evm ecosystem and also like uh cosmos environments which is a wasm framework that we have in cosmos um and so like we can have the same way we have like erc20s coming from these these different interoperability clusters avm and pocket that come into cosmos we can also have nfts from from solana for example or from avalanche or polygon that can come to the cosmos ecosystem via evm bridges and then be transferred to the rest of the cosmos to uh through these ivc cross chain nft uh standard that we're trying to implement and then you also have like more complex use case like cross chain delegate calls um where you don't need to deploy a smart contract twice on different evm chains but you can like deploy it on mmos and then if you have like another smart contract that is deployed on another evm chain in the cosmos ecosystem you can send an ivc transaction to in order to call the smart contract and then execute some behavior once a pocket acknowledgement is processed on on atmos for example so you can create interchange composability through this uh mechanism right now so we can forget about the current strategy that a lot of d5 dubs have at the moment that are deploying and and the different evm chains um which is going to be enabled right now with this cross-chain delegate code that's that we are going to be providing through the entire interoperability on the final the final model is interchange composibility this is a bit different than the example i explained before which is cross-chain delegates like two evm uh two evm chains or for example an evm with a cosmo awesome smart contract environment that can enable like interoperability between the smart contracts here instead we're allowing non-evm chains or any chain in the cosmos ecosystem to talk to a smart contract natively and get the logs or the events from the received directly on their application so that they can handle application specific logic that is targeting a individual smart contract so what this is enabling is the you don't need to necessarily build your application specific logic and you can scale faster by just deploying a smart contract on fmos and having these all these other chains talk to these smart contracts and then scaling through by only handling the specific events that are targeting the um the atmos chains and then finally i'm going to talk about all these the different resources that we have on how you can connect to the atmos testing that is currently live on how you can learn more about atmos on all the uh developer documentation that we have and you can learn more about the architecture so where the first thing is like you can connect already to fms test net here you can find uh some of the um like available uh notes public available inputs that you can find which is the uh customs grpc custom unrest which is handled through grpc gateway um and then you have like the term domain rpc the ethereum json rpc so that you can connect metamask under your ethereum tooling already and we also support the ethereum websocket through block daemon which is kindly providing all this infrastructure for the public we also have like the atmos chain grpc gateway docs so you can already query through these nice interface all the um all the different like rp uh like rest endpoints that you can interact with the atmos test net already so this is actually targeting here you can see like the base url is targeting uh the testnet and then you can also learn more in our different uh resources and links that we are providing here the first of them is our documentation which you can find on atmos.dev we have all the documentation of how to connect to the testnet how to connect to mainnet which we are relaunching on this tuesday and you can also find documentation on how to interact with these rest endpoints on or how to run a validator or a node or how to set up a local a local net so that you can interact with your smart contract locally if you want to learn more about like the core development efforts that we're doing you can go to github and find us on on the thor sys repository uh on fmos we also have a javascript library that provides address conversion tools for how to convert back 32 to hex available addresses that kepler is also using to support ethereum compatible addresses and you can also find like protobuf transaction declarations and definitions so that you can send transactions on cosmos um using like kepler or we also support for example like all the transactions formatted using um eip uh sorry eip seven trolls which is a meta transaction format and ethereum that allows for example metamosque to sign cosmos transactions or sending transaction via ivc so that as a user you don't need to change your existing wallet to interact with the cosmos ecosystem or you don't need to necessarily export your private key you can already do that natively using this library on connecting metamouse through eip712 and then finally if you want to know more about the evm we have the ether main library ethernet was a pre-evolution of atmos which is long-standing library for how to develop an evm module on cosmos thank you very much i'm not sure how much time i have left i think this is um any questions hey how's it going and then like if a user wants to withdraw so to go back then like how do you decide which which seconds will withdraw what do you mean drop so if i understand correctly let's say if i move usbc to um to imos and amari will send usdt to ismos and if most governments decide that usdc is the principal one then both of us will visit oh yeah that's a that's a good question so um he's he's asking i'm going to repeat your question so that it gets recorded um he's asking about the erc20 module and how the registration process is handled and how the um for example like the community votes for one smart contract in particular against others and how do we decide which one is a canonical one and which one is dropped or not from community point of view right when i'm like having the usbc but originally i provided usbt yeah then like going back to interim how do you decide like which the users will see yeah so for for evm so like you define a smart contract address and you define for example like which is going to be like the canonical for example um usdc that is coming from ethereum to uh the fmos chain that is all voted through governance and the governance community needs to provide like verifiable smart contract um they need to provide a repository documentation they need to provide like for example like um the hash of the contract and they need to be like usually the proposal will have to be uh proposed by either the developers or certain core member users from the community so that we know that it's actually that development team that is creating that proposal so there's like needs to be a lot of due diligence from the community in order to actually know what is a verifiable valid contract versus what is just another deployment of the same open source code base right um and so from the other side how do you decide like which is going to be like the um like the smart contract representation of a cosmos asset that will go that will be available in the evm and then can be transferred out to the pocketed or the evm ecosystems is once you create us the proposal you can automatically register we have a factory we have a factory contract that is gonna once the proposal is approved we're gonna deploy a smart contract specifically for that ivc voucher so that we limit the thread in terms of security of having multiple smart contracts that are not owned by um the core team or the um yeah like it can be like a fake uh deployment for example so like by creating a factory contract of the ivc voucher the actual it's a core protocol the owner of or the deployer of the smart contract so you can create like the um approval processes for converting the erc20 and changing the the supply of the token like minting and uh burning usd on each monster will be like usdd yes or usde right like the merged token for representing various usd tokens then if i want to send the usd e back to ethereum then i will not receive neither of the original tokens i will receive usde new usd token ontario um that is done specifically by whatever breach you're using so that depends exclusively we're only handling this from the evm to the cosmos representation but we are not handling how the same representation of the smart contracts on the evm is going to be represented on say ethereum or polygon etc that depends so they're like going to be like different bridge solutions deploying on atmos and the user will have to based on the uh trade-off that they found in terms of security speed etc they can select whatever uh and also fractionality um they can choose whatever breach provider they prefer so will it be possible to bridge into atmos uh something that does not have yet official representation like voted by government so i have some random year signature talking can i just bridge it right into a headmaster yes so the question is like what can i can breach a token that is not voted through governance uh to atmos um yes so that's so if you are on the avm ecosystem on any other evm chain and then you have like a random erc20 token whatever it is you can use um any breach provided like nomad connects etc and you can reach these tokens to atmos but in order to support that evian the token in the entire interchange ecosystem in the entire customs ecosystem that token will have to be voted through governance and the requirements uh in terms of like um due diligence the the entire governance community is going to do is like first having like the contract be verified in the um in the vlog explorer for example the the source code is publicly available and that you're not introducing some malicious malicious action in terms of like oh when a token is transferred by a user you're not for example like emitting a like a ghost approval where you can drain all the user funds so like like the community needs to vote and that's why we're doing all this due diligence process but that's only for how to represent the same token as a cosmos asset and then can be sent back so that's that's why we're doing this mechanism through governance it's in terms of like how to prevent these malicious erc20s from being deployed on the rest of the interchain ecosystem yeah you can use you can use any bridge provider to reach those tokens to atmos and then create your governance proposal to get that token into the rest of the interchange ecosystem this as i mentioned is just for security messengers to prevent malicious er c20s that drain users funds because they're not tokens that are necessarily owned by the protocol but are owned by certain contract owners or deployers that's why we're trying to mitigate the amount of malicious years 20s in the ecosystem well thank you very much for your time we'll be here if you have any questions [Applause] anyone here [Music] [Applause] [Music] you