those of you who are here last year and
happened to come to our talk might
recall ether meant a 1.0 well we're back
in ether MIT is back but this time it's
better so I'm gonna talk about ether at
2.0 which combines the best features we
think of aetherium the EVM and the best
features of the cosmos SDK and tender
mint 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 tournament consensus and
how it facilitates this model of
interconnected blockchains
then we'll talk all about Ethernet 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 DAPs or move parts of
your jobs 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 block chains 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 block chain 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
Kosmos 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 the control which stores can be
read or written to unlike for example a
call between contracts in the EVM a call
between modules and the cost
that's decay 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 for 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 now and
eventually not only us we hope but many
other people who are building these
application specific block chains they
can build modules as we've built for
governance staking fee distribution and
inter blockchain communication they
could build a different module for add X
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 block chains we need a
consensus algorithm with particular
properties so we've built tenement
tender mint 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 superfast
two-and-a-half second block times ten
Dermot 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
tender mint 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 ten durmand so here's a
picture of what the tenement stack looks
like so you can see this in visual form
the large green rectangle is tournament
consensus and each of the circular disks
is a validator participating in the
consensus algorithm sending messages to
each other to vote in BFT rounds then in
smaller blue rectangle we have the ABC
i-- allocation that's your state machine
written using the cosmos SDK and perhaps
featuring the EVM which is talking to
and from ten Derman telling ten Dermot
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
intendment 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 in which we invite any
blockchains 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 delegate errs are liable
have their valid at our commits a
protocol fault they validate or double
signs or fails to participate in
consensus for too long the delegate errs
too can be slashed bonded proof of stake
addresses the nothing at stake problem
with a nun bonding period both
validators and delegate errs when they
want to participate to vote in consensus
have to lockup tokens for it will be
three weeks at launch for the cosmos 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 module
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 parameterize
our slashing and staking conditions all
total object of delegation or punish
people differently for committing
protocol faults
the second core module is governance
like our proof of stake module
government's design is designed to be
pretty flexible so it will 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 promising parameter
change proposals which are inbound so if
a parameter change proposal is passed
that might change the amount of steak
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
is 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 tender mint block
chains there will be a few hundred or so
validators those validators going to
vote and by default they were carry
their delegate errs 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
delegate errs can also elect override to
vote other validators if they disagree
and they will have time to do that if
they see what the reality to 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 tender mint than for most existing
block chains 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 das the current
elected proposer so we just distribute
most rewards for posting proportionally
to stake held by all the delegate errs
and Vala leaders 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 block
with your own token easy peasy just
changed one string and it also supports
multi coin fees so we think the economic
module model approves take may be a
little different for example for the
cosmos Club we plan to accept
transactions or we plan to encourage the
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 block chains on
top of this authenticated exactly ones
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
block chains you could implement
transfer of unique tokens which mean
you're conserving the existence of the
particularly 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 in some kind of sharding then
the special module for this presentation
is the EVF so in ether mint 2.0 we've
taken the e via in the etherium virtual
machine which is the core part of the
etherium block chain 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 aetherium transactions
that's how we've been testing our EVM
implementation by running the actual
theorem transaction history but most
interestingly it can call to and from
cosmos SDK modules so if you have a
block chain 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
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
either 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 and the
other causing assist eke eight modules
so ether meant 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 ten durman's
Byzantine fault tolerant consensus 2
second block latency instant finality
the power of the cosmos SDK lease
capabilities security the ability to
integrate all these modules and
contribute downstream and the existing
ecosystem of etherion contracts and
development tooling truffle metamath
solidity you name it
but we've even done more than that not
we have not just poured it as an ether
mat 1.0 the evo module from death we've
ported the Evo module from turbo goth
which Alexei 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 really
call in to other cosmos SDK modules or
vice versa Turbo goth I will encourage
you to take a stop at Alexie's talk
which is tomorrow afternoon same time
but in brief a turbo gap which is being
developed in parallel as an aetherium
client along with the cosmos sdk module
has numerous improvements over the
current available EVM implementations it
supports any binary search tree has
structure preserving custom
serialization as opposed to our LP which
is much faster it allows you to use the
same data structure for database
indexing and merggle hosting also faster
and it implements a 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 sink past
transactions and verify them now there
are two ways to use the EVM module as
I've alluded to ether mint will exist as
a particular block chain as a proof of
stake chain with all the core modules
with the EBA motto and with a web 3
interface for running smart contracts
but the EVM ECHA 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 in economic model you
want the e thurman 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 a thurman were
planning to copy balance subject to
approval by cosmo sub governance to copy
balances from the etherium chain
possibly also atoms from the cosmos
chain and use that to seed the photon
token which will be the native token on
a thurmond ether meant we'll have we
plan shared security with the cosmos hub
meaning that anyone who wants to attack
either mint would have to pay the
combined cost of attacking two block
chains of course this will all need to
be approved by cosmos self governance so
we're focusing on building the software
to enable heart Spoons
in any configuration you want or maybe
even a hard sport which dices upstate
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 where does a blockchain is
designed to be like aetherium one chain
for many EVM applications at once well
hard Spoon account balances so users can
start out with tokens to start using the
chain ether MIT will be a sovereign
chain having photons you don't need
anything other than photons in order to
use ether meant it will also have the
governance staking and sashing modules
from the cosmos SDK
using tenement consensus it will be
fully web 3 compatible so you can use
truffle metamath solidity all your
existing tooling you know change a
drop-down slider and madam asked can
connect to ether mint instead and it
will have IBC connections to the cosmos
hub into future zones which will inhabit
the cosmos network the VM module for sdk
zones provides 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 EVO 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 is
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 a theorem they have state on
ethereum tokens collect crypto
collectibles and some people want to
start using the new ether and 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 aetherium on
to ether mint or on to a sovereign zone
with the via module and to withdraw from
the sovereign zone back to the etherium
main chain then you can select which
parts of your logic are most improved by
the new features of ten Dermott's in the
sdk and put those on ether mentor put
those on the sovereign chain and allow
you users to retain assets or wallet
balances at least for a little while on
theorem how do we do this we've
developed at cosmos a technology called
inter blockchain communication which
allows for this kind of generic two-way
bridge in order to bridge ether mint to
aetherium we need to separate IBC
connections we need one IBC connection
a Thurmond and the Kosmos hub which is a
blockchain that we're launching soon and
we need another IVC connection between
the cosmos hub and etherium then tokens
can flow through those two connections
so someone can deposit from aetherium
some ether that ether will head over the
IVC 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 Ani Thurmond
what is this IPC bridge allow for the
answer is pretty much anything IBC is
payload agnostic so it will take some
byte string from these two chip from one
chain to another or from two across two
bridges from etherion to Thurmond then
IBC modules on etherium and on a
Thurmond will expose this primitive to
contracts so that you can write
contracts which transfer tokens which
transfer assets which do much more
complicated thing is like execute cross
chain dependent smart contract logic or
move code between chains hopefully this
will allow adapts to put parts of their
logic that are most fee sensitive or
most time-sensitive and execution speed
on a Thurmond and leave some parts on
aetherium
for existing DOPS we think like I said
this is super compelling you can move
parts of your contract logic overtime
when you need to execute an expensive
transaction you shift over to either
mint and the ux4 users can be pretty
seamless abstracted over and all the web
3 tooling a particular example would be
porting a Dex porting a decentralized
exchange protocol like Xerox or wyvern
to an ether mint zone so you could copy
the protocol contracts on to e thurmond
deploy them to the Evo module get them
running then allow users to deposit
tokens over the IBC bridge or even non
fungible x' from aetherium 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 it acts 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 Evo module
on the sovereigns own but then you could
add some improvements you 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 is 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
pointing parts of the Dex protocol I'll
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 sneaky
mechanics maybe add new slashing
conditions to prevent front-running or
implement alter the state machine
implement threshold decryption so that
transactions are encrypted when they're
submitted to the blockchain and decrypt
it 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 vaporware you can find
it on github development is progressing
exceptionally quickly worked on by bears
who's sitting in the audience and by
Aleksey who will 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 solidity
contracts to the EBM 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 etherium 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 Dax 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
rewards with a 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
etherium 2.0 talk which was super
interesting and I'd 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 will provide very
fast finality which were thrilled about
because it will allow even faster IBC
connections from aetherium 2.0 to ether
mint to cosmos to any other chains which
implement this kind of entertaining
protocol so first I will my pitch or ask
is that you head on over to cosmos
network slash DEFCON 4
fill out the survey maybe you 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 City 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 have five minutes for questions
when is the tournament going life when
is the interment going live excellent
question so we anticipate Developer
Preview release at the end of q4 and
then the actual deployment of interment
will be up to Cosmo sub 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
Kosmos hub and be through main chain
fully specified partially implemented
you can find the spec on the cosmos SDK
github 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 teens not
using tender but not using 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 is not a go
will be slightly harder but still
possible if you deploy a EVM module it's
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 your users to play
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 appointment to
require that it be approved by the
validator side or something like that
sorry if I miss this but like can you
memorialize the internment State on the
route chain so for example I you could
use like the so IBM to invalidate state
transitions on the route chain is that
possible that is a extremely interesting
question in principle yes the 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
think that wouldn't be too hard the EVM
is inspect compliant so if you have a
spec compliant interpreter on in
solidity on the etherium a chain to work
hi if I want to make the transaction
between two block chains both with
cosmos SDK do I need 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 a Thurmond 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
you