 Those of you who are here last year and happened to come to our talk might recall ether mint 1.0 Well, we're back and ether mint is back, but this time it's better So I'm gonna talk about ether mint 2.0, which combines the best features We think of a theorem the EVM and the best features of the cosmos SDK and tendermint In this presentation first, I'll give a quick overview of cosmos explain the network model the topology Why we think it makes sense I'll talk about the feature set of the cosmos SDK in particular and how it can be combined with the EVM And I'll give a quick background on tendermint consensus and how it facilitates this model of interconnected blockchains Then we'll talk all about ether mint 2.0. I'll outline the architecture the chains will be made from ether mint 1.0 And why I'll talk about how the EVM and the SDK can work together to give you native code and EVM contracts all in one blockchain I'll talk about finally how you can move your dApps or move parts of your dApps on to the ether mint chain While preserving seamless UX and I'll take any questions So first the cosmos model envisions a network of interconnected block chains in many ways these blockchains will be application Specific they will do lots of different things but talk to each other in order to facilitate this We need to make it really easy to build an application specific blockchain to do that We've built the cosmos SDK the cosmos SDK is a framework for building custom state machines It contains all the glue library code of blockchains AVL trees Message handlers all the logic to knit modules together Super developer friendly. It's written in Golang, which many of you are probably familiar with it's all open source on github The cosmos SDK is designed in particular to be secure to make it easy to use different modules Which do different things which can interact with each other But where you can control the ways in which they interact so you can mitigate unintended consequences To do this we use something called least authority permissioning So you pass around keys from one module to the other keys that control which stores can be read or written to Unlike for example a call between contracts in the EVM a call between modules in the cosmos SDK can only Execute reads or writes to the stores for which you give it permission to do We're trying to model the SDK as a sort of ruby on rails for blockchains a way to take existing modules Add your own custom flavor for your particular application and end up really fast with something that's production ready In order to do this the SDK needs to be modular We've built a system by which we can build particular components that you might want in your state machine as modules Not and eventually not only us we hope but many other people who are building these application specific blockchains They can build modules as we've built for governance staking fee distribution and inter blockchain communication They could build a different module for a dex or a different module for a different kind of proof-of-stake algorithm Then you can using the cosmos SDK pick and choose which modules you want to use in your blockchain glue them together And connect them using the least authority permissioning system to run your state machine We hope then when you've done this and when you've added your application specific flavor the custom module for whatever your Blockchain is going to do better than anyone else You will share that or share parts of it upstream so that people upstream and downstream so that people can build upon what you've done Improve it and send it back in order to facilitate this network of interconnected blockchains We need a consensus algorithm with particular properties. So we've built tendermint Tendermint is the state-of-the-art Generic Byzantine fault tolerant blockchain engine it encapsulates the consensus in peer-to-peer layer Coming to consensus on which transactions ought to be applied in which block and when a block needs to be appended to the chain And it provides vertical layer one scaling for your state machine super fast two and a half second block times Tendermint is fully peer reviewed and it offers one block finality as soon as the block is confirmed. It will never be reverted Most importantly for this model of application specific block chains tendermint is generic It can connect to any state machine You could write using the cosmos SDK or using a different SDK any kind of state machine You like operating whatever sort of application you want to operate and run it with tendermint So here's a picture of what the tendermint stack looks like so you can see this in visual form The large green rectangle is tendermint consensus and each of the circular disk is a validator participating in the consensus algorithm sending messages to each other to vote in BFT rounds Then in the smaller blue rectangle. We have the ABCI application That's your state machine written using the cosmos SDK and perhaps featuring the EVM Which is talking to and from tendermint telling tendermint which transactions are valid and executing the transactions once they've been confirmed in a block So in order to make it as easy as possible for developers to start working on Full-function block chains using the SDK and tendermint and in order to build the particular block chain We're working on the cosmos hub. We've built some core modules, which I'll talk about now The first module is bonded proof-of-stake Bonded proof-of-stake is the proof-of-stake mechanism which will be used by the cosmos hub and which we invite any block chains in the cosmos Ecosystem to use themselves with their own staking token if they like Bonded proof-of-stake has delegation as we say with skin in the game So delegators are liable if they're valid or commits a protocol fault They're valid or double signs or fails to participate in consensus for too long the delegators to can be slashed Bonded proof-of-stake addresses the nothing at stake problem with an unbonding period Both validators and delegators when they want to participate to vote in consensus have to lock up tokens For it will be three weeks at launch for the cosmos hub But for a configurable amount of time and as long as those tokens are locked up if an infraction is discovered They can be slashed We've tried to build this model module to be batteries included but Extensible you could import it as is and have a fully functional proof-of-stake algorithm for whatever state machine you're running or you can modify it You could add custom slashing conditions for different kinds of Application level guarantees you want to provide or you could change the way we've parameterized are slashing and staking conditions To alter the logic of delegation or punish people differently for committing protocol faults The second core module is governance Like our proof-of-stake module governance design is designed to be pretty flexible so we'll work for lots of different blockchains Our governance module has different kinds of what we call governance proposals proposals to change some way the chain works The first are simply text proposals They don't do anything in protocol in band but rather allow for the network to come to social consensus on Maybe some change to make in a future software upgrade or on some way in which we want to change the way we're operating this blockchain The second are parametric parameter change proposals, which are in-band So if a parameter change proposal is passed that might change the amount of stake which is slashed for double signing Or it could change the annual network inflation rate Third and finally we have software upgrade proposals which actually upgrade the state machine Which the chain is running so upgrade in the case of your application specific blockchain may be the logic of an exchange Once everyone has come to consensus on that proposal at a particular block height automatically For governance, we've elected to use liquid democracy So in tendermen blockchains there will be a few hundred or so validators Those validators can vote and by default they will carry their delegators vote with them If your validator votes for in favor of a proposal and you as a delegator Elect to do nothing your vote your stake will count in favor of the proposal But delegators can also elect override the vote of the validators if they disagree and They will have time to do that if they see what the validator votes for and decide they don't like it Next up on the list of core modules is fee distribution rewards and fees We have decided that we need to use a pretty different system for fee distribution for tenderment than for most existing blockchains We can't just give all the fees to the proposer because it would make it too much of a Incentive to bias proposer election or DOS the current elected proposer So we just distribute most rewards Proportionally to stake held by all the delegators and validators on the blockchain Like the staking module and the governance module our fee distribution module supports any token So you could integrate it into your application specific blockchain with your own token Easy peasy just change one string And it also supports multi-coin fees So we think the economic module a model of proof of stake reveal a little different for example for the cosmos hub We plan to accept transactions or we plan to encourage a validator set of the cosmos hub to accept transactions Which pay fees and lots of different denominations. They don't need to be atoms The final core module and my favorite is inter blockchain communication So this is the key part of what makes the cosmos network model tick We've exposed the IBC interface, which is a payload agnostic way of sending Authenticated messages exactly once to another blockchain. It's a little like TCP IP for blockchains on top of this Authenticated exactly once message delivery primitive you can implement lots of different application level guarantees You can implement token transfer, which means that you're conserving supply across two different blockchains You could implement transfer of unique tokens, which means you're conserving the Existence of the particular unique token on only one chain In only one account at a time you could transfer data or you could even transfer code parts of your smart contracts and some kind of sharding Then the special module for this presentation is the EVM So in ether mid 2.0, we've taken the EVM the Ethereum virtual machine Which the core part of the Ethereum blockchain that runs all your smart contracts and put it in a Cosmos SDK module Has all the features you're used to an account database and a state tree it can run Ethereum transactions That's how we've been testing our EVM implementation by running the actual Ethereum transaction history But most interestingly it can call to and from Cosmos SDK modules So if you have a blockchain with the EVM module with the governance module with the staking module Contracts you write for the EVM module can talk to the staking module. Maybe they could delegate Maybe they could query balances. Maybe they could see when people got slashed or do things when that happens similar for governance for fee distribution and for IBC So if you have an EVM contract on a blockchain in the Cosmos SDK along with the IBC module Contracts running on that EVM module can make calls through IBC to and from other blockchains In order to enable this we need and we have implemented a shared state view So there is one token or only needs to be one token on this blockchain Which will be ether quote-unquote in the EVM message dot value for those of you familiar with solidity But which will be the token used for governance possibly for proof of stake and fee distribution in the other Cosmos SDK modules So ether mint the whole package combines the Cosmos SDK all of these core modules We've built the EVM module and a web 3 API layer We think this provides a pretty compelling deal you get the scalability of tendermans Byzantine fault tolerant consensus to second block latency in finality the power of the Cosmos SDK these capabilities security the ability to integrate all these modules and contribute downstream and The existing ecosystem of Ethereum contracts and development tooling truffle metamask solidity. You name it But we've even done more than that Not we have not just ported as an ether mint 1.0 the EVM module from Gath we've ported the EVM module from turbo gap which Alexi is working on that is Features a lot of improvements over the base EVM. It's faster. We've changed up how the database works Of course, it connects through the SDK module interface So you can have what are like pre-compiles in the EVM But which would really call into other Cosmos SDK modules or vice versa Turbo geth I will encourage you to take a stop at Alexi's talk Which is tomorrow afternoon same time but in brief a turbo geth which is being developed in parallel as an Ethereum client along with the Cosmos SDK module Has numerous improvements over the current available EVM implementations. It supports any binary search tree It has structure preserving custom serialization as opposed to RLP, which is much faster It allows you to use the same data structure for database indexing and mergel has thing also faster And it implements some new caching strategies in particular for state sync using the benefit of hindsight So using the fact that you know what future transactions are or future states when you're trying to sync past transactions verify them Now there are two ways to use the EVM module as I've alluded to Ether mint will exist as a particular blockchain as a proof-of-stake chain With all the core modules with the EVM module and with the web 3 interface for running smart contracts But the EVM module will also exist as a library The EVM module is a library will allow you to deploy your own Cosmos chain with EVM support add in other SDK modules in whichever combinations and parameter choices you like And choose whatever token and economic model you want The Ether mint chain will also be launched with a term you might have heard the hard spoon What's a hard spoon a hard spoon is to copy the token distribution Including multi signatures from another chain onto a new chain So in particular for Ether mint we're planning to copy balance subject to approval by Cosmos sub-governance to copy balances from The Ethereum chain possibly also Adams from the Cosmos chain and use that to seed the photon token Which will be the native token on Ether mint Ether mint will have we plan shared security with the Cosmos hub Meaning that anyone who wants to attack Ether mint would have to pay the combined cost of attacking two blockchains Of course, this will all need to be approved by Cosmos of governance So we're focusing on building the software to enable hard spoons in any configuration You want or maybe even a hard spork which dices up state and rearranges it But we do expect To propose this particular plan and we expect photons will be accepted as a fee token on the hub Which is super important for user experience as I'll get you later So either way does a blockchain is designed to be like a therium one chain for many EVM applications at once We'll hard spoon account balances so users can start out with tokens to start using the chain Ethermint will be a sovereign chain having photons You don't need anything other than photons in order to use Ether mint It will also have the governance staking and slashing modules from the Cosmos SDK Using tendermint consensus It will be fully web 3 compatible so you can use truffle metamask solidity all your existing tooling You know change a drop-down slider and metamask and connect to Ether mint instead And it will have IBC connections to the Cosmos hub and to future zones which will inhabit the Cosmos network The EVM module for SDK zones provides some different trade-offs So in this case you could elect to deploy a Cosmos chain, which includes Some of our base modules and some modules of your own and also an EVM module You could even add our web 3 interface if you want This means you can utilize existing solidity contracts as part of the logic on your new application specific blockchain And it means that if you're trying to port an application, which was previously targeted towards the EVM To an application specific blockchain you can do it gradually You can start out with your solidity code perhaps deployed to an EVM module And you can replace the performance critical parts of that code one at a time out with native code Maybe all the way maybe not, but we come to a problem. What if we do that? You launch a new application specific blockchain, but now your users are split or your potential users are split Some people are on Ethereum. They have state on Ethereum tokens collect crypto collectibles and some people want to start using the new Ether mint chain We need a way to connect them We need a way to transfer state and assets in a two-way bridge Where it's possible both to deposit if you will from Ethereum onto Ether mint or onto a sovereign zone with the EVM module And to withdraw from the sovereign zone back to the Ethereum main chain Then you can select which parts of your logic are most improved by the new features of tendermint and the STK And put those on Ether mint or put those on the sovereign chain and allow your users to retain assets or wallet balances At least for a little while on Ethereum How do we do this? We've developed a Cosmos a technology called inter blockchain communication which allows for this kind of generic two-way bridge In order to bridge Ether mint to Ethereum. We need two separate IBC connections We need one IBC connection between Ether mint and the cosmos hub Which is a blockchain that we're launching soon And we need another IBC connection between the cosmos hub and Ethereum then tokens can flow through those two connections So someone can deposit from a theorem some ether that ether will head over the IBC connection to the cosmos hub And then it will be bounced on from the cosmos hub to Ether mint where it can be used in Smart contracts operating on the EVM module on Ether mint. What does this IBC bridge allow for? The answer is pretty much anything IBC is payload agnostic So it will take some byte string from these two from one chain to another or from two across two bridges from Ethereum to Ether mint Then IBC modules on the theorem and on Ether mint will expose this primitive to contracts So you can write contracts which transfer tokens which transfer assets or which do much more complicated things like execute cross-chain dependent smart contract logic or move code between chains Hopefully this will allow dApps to put parts of their logic that are most fee sensitive or most time sensitive and execution speed on Ether mint and leave some parts on a theorem For existing dApps, we think like I said, this is super compelling You can move parts of your contract logic over time when you need to execute an expensive transaction You shift over to Ether mint and the UX for users can be pretty seamless abstracted over in all the web 3 tooling a particular example would be porting a DEX porting a decentralized exchange Protocol like 0x or Wyvern to an Ether mint zone So you could copy the protocol contracts on to Ether mint deploy them to the EVM module Get them running then allow users to deposit tokens over the IBC bridge Or even non fungibles from Ethereum to Ether mint once they're deposited to Ether mint They can be used and traded in the stacks and kept there indefinitely if you like and if users want or want to have the option to Withdraw back to the Ethereum main chain. They can do so with no permission on your part You could also implement a DEX as a sovereign zone using the EVM module with the same initial starting procedure of porting the contracts from solidity and deploying them on to the EVM module on the sovereign zone But then you could add some improvements You could first of all you would have no competition for block space So if you run a sovereign chain for just the DEX only your DEX's transactions would be settled there You could prevent anyone else, you know any crypto kitties hit of the month From crowding out your block space and making it expensive for your users to trade You could also start porting parts of the DEX protocol probably trade settlement execution The super gas expensive parts to native code as SDK modules, which would make it much cheaper And you could change more complex things you could alter staking mechanics Maybe add new slashing conditions to prevent front-running or implement all to the state machine implement Threshold decryption so the transactions are encrypted when they're submitted to the blockchain and decrypted later So no one can front-run on the DEX all of this is possible if you have a sovereign zone So what's the state of all of this? Ether mint is not a vaporware you can find it on github development is progressing exceptionally quickly Worked on by Bez who's sitting in the audience and by Alexei who'll be giving a talk tomorrow We're anticipating a developer preview release, which will have a functional or 99.9% functional web 3 API By the end of Q4 this year and which will allow you to deploy slidity contracts to the EVM module and play around with either mint And we encourage you to check it out send us feedback tell us what you would like tell us what the challenge is facing This kind of application deployment process are There of course many questions we haven't answered yet We're not quite sure how contract balances ought to work in proof of stake There are lots of contracts say on the Ethereum main chain right now, which hold a lot of ether Should they be able to delegate what happens if they get slashed? What happens if you deposit your tokens to to a dex contract that dex contract delegates then they get slashed Are you responsible? Maybe we want to figure that out We haven't decided what the exact token models for fee only tokens since we have delegated security ought to be will they be The same or similar as proof of work remords with the declining exponential Maybe they will be flat 500 tokens per hour for the until the end of all time lots of opportunities to experiment of Course I just went this morning to the Ethereum 2.0 talk, which was super interesting And I haven't had a chance to update this slide But it sounds like they're now switching to a version of proof of stake which would provide very fast Finality which we're thrilled about because it will allow even faster IVC connections from Ethereum 2.0 To either mint to cosmos to any other chains which implement this kind of interchange protocol so first I will My pitch or ask is that you head on over to cosmos.network slash devcon for Fill out the survey maybe mentioned that you came to this talk Ask us any questions and that you head on over to our booth for a chance to win a sweet Cosmo study But even more importantly ask us questions about ether mint how you can use it what we're up to how we can help Any questions? Thank you very much. We are five minutes for questions When is the term and going live? When is the term and going live excellent question? So we anticipate developer preview release at the end of Q4 And then the actual deployment of you through it will be up to Cosmos hub governance. So that might be you if you're voting Was the status or was the state of the development of the bridge between the Cosmos hub and The Ethereum main chain fully specified partially implemented You can find a spec on the Cosmos SDK get a repository and you can also find a prototype implementation Are you planning to support inter blockchain communication with with chains that are not part of Cosmos? Yes, absolutely The spec for our IBC is already open open source and we encourage anyone to contribute and we Absolutely encourage people who are not Cosmos chains not using tendermen not using the SDK to implement that protocol How portable is your EVM? Can I use it from for example a hyper ledger project or something else? It will depend a little on the project if the project doesn't go It will be super easy if the project does not ago be slightly harder, but still possible If you deploy a EVM module is the idea that you would restrict what contracts can be deployed into that Blockchain essentially so you're not competing for you know resources with other contracts that users deploy Yes, yes, so you could deploy an EVM module and not allow contract deployment at all After you've like launched the blockchain Which might be what you want to do in a sovereign zone or you could allow limited contract deployment to require that it be approved by the Validator set or something like that Sorry if I missed this but like can you memorialize the Etherman state on the root chain so for example like you could use like the sole EVM to invalidate stage Transitions on the root chain. Is that possible? That is an extremely interesting question In principle, yes Cosmos IBC model doesn't have that doesn't need State fraud proofs to work necessarily But if you wanted to implement something that did or you just wanted them anyway for extra security I think that wouldn't be too hard. The EVM is spec compliant So if you have a spec compliant interpreter on insolidity on the Ethereum main chain to work Hi, if I want to make a transaction between two blockchains built with Cosmos SDK Do I need the atoms? Oh Right, thank you. I alluded to it and then forgot to answer that question So thank you for asking it That's one of the reasons we think the photon hard spoon is super compelling because it will make that unnecessary Because if photons are accepted as a fee token on the hub and on Ethermint then users can transfer assets over both of those IBC bridges Without needing to acquire any new tokens last question I'm curious what the user experience is like when you're moving across these chains We hope that it will be seamless. It's not going to be seamless at first But it's possible in principle to abstract over Most of the transactions and because IBC already provides this cross chain state verification You can basically pay fees once and cover all of the transactions