I'm Chris I work from tournament
research and I'm going to talk a bit
about and I'll explain what the terms
mean don't worry interblock team
communication and the topology of the
inter chain the polycentric inter chain
is already here let's unpack this in the
past few years we've seen what I like to
call a Cambrian explosion of black
chains it's continuing even more several
new protocols were announced of this
event one hypothesis says that these
block chains will be selected out and
slowly converged to a few single
Ledger's which handle all of the state
transitions all of the currency
transactions all of the future complex
decentralized financial protocols etc
perhaps but another hypothesis says that
the interchange will continue to branch
out words that new protocols will
continue to be built which can
specialize on different sorts of use
cases that new assets will continue to
come into existence that assets and
protocols will perhaps dissociate
somewhat where an asset can retain its
logical identity while living on a
different and perhaps improved protocol
that's what I mean by the interchange
this set of Ledger's fulfilling a set of
different use cases why might we want
this there are a lot of advantages to
having separate block chains as opposed
to a few single ones one advantage is
versatility different protocols can
focus on two different use cases they
can optimize their state machines
optimize their educational materials
focus their community focus their
onboarding focus their user experience
on solving certain specific problems
really well as opposed to solving a lot
of problems not so great this applies
not only to the case of simply building
a protocol but also to the case of
governing and governing it over time if
a single protocol has to cater to a wide
diversity of use cases all of the
interests of different users who
probably want different things and for
whom the protocol moving in different
directions would be better or worse at
different times
have a hard time agreeing on how to
change a protocol over time that becomes
much easier if a use case is more
focused if they can choose to focus
their particular protocol and solving
one particular problem and if they need
a new problem build a new protocol
another thing which I think is really
important and sometimes under emphasized
is minimizing exit costs of distributed
Ledger's right now many of us I think
would consider the exit costs of
centralized platforms particularly those
which control information to be too high
but one of the reason the exit costs of
Facebook or Twitter or Google suite are
so high is that there's no possible
interoperability if someone builds a web
client which allows you to access your
Gmail data Google will sue them or shut
it down or prevent API access I think we
should have the same concern in the same
desire to minimize exit costs for
Ledger's and that means continued asset
interoperability so hard Forks can be
contentious when they necessarily
diverge when it's not possible for users
to continue to use both protocols at
once but if hard Forks could instead be
Rican stood under a new mechanism where
two different versions of a protocol can
continue over time then people could use
one version retain their asset other
people could choose to switch the new
version and retain the same logical
continuity moving their assets to and
from the original protocol but in order
to do all of this we need a way for
these different block chains in the
interchange to talk to one another this
way or a way that we've been developing
is ibc inter blockchain communication
IBC is a messaging protocol for the
inter chain a general messaging protocol
let's go back in time a few decades to
the early internet when some similar
problems were being solved different
machines and often different sort of
localized clusters and machines existed
in different places around the world
particularly an ARPANET around CERN in
universities in the United States and in
Europe and later across the world and
those computers needed a way to talk to
each other this was obvious
many people built protocol
to allow these computers to talk to each
other and some of them I listed on the
slide so we'll have a quick quiz raise
your hand and keep it up if you've heard
of X NS hmm not too many Apple talk a
few chaos net IP x SP x IP should be
just about everyone he came to this
conference divided by a ticket using the
Internet Protocol almost certainly why
why were what for for these protocols
there are tons more which I didn't
bother the lists Huayra for these
protocols unsuccessful in connecting all
of the computers while one was I think
there are a few reasons one is that the
Internet Protocol was quite general it
wasn't specific to a manufacturer or
specific to somewhat closed hardware
like Apple Talk it didn't rely on
particular network cards it wasn't in
humored by patents it was something
where anyone could read the open-source
protocol standard or what was
open-source in that time and implement
their own Hardware which supported it
protocols like some of these and
especially IP are non-contentious the
Internet Protocol has a monopoly there
are no other internet protocols but it's
a beneficial monopoly or but Neverland
monopoly because using the Internet
Protocol doesn't prevent anyone from
supporting other protocols it doesn't
lock them into a particular token a
particular infrastructure as they just
speak this particular language at the
edge where they connect to other
computers we need something similar for
block chains what does this mean in the
context of blockchain interoperability
how do we build this kind of protocol
which can fulfill this non-contentious
global standard requirement one needs to
be modular this communications protocol
needs to abstract over the different
methods for verifying state of other
block chains it needs to enable needs to
create a standard such that block chains
can check the other blockchain sent
messages to it needs to be local the
stands in contrast to a lot of charting
protocols which are interesting there's
all the different problem but charting
protocols tend to require a glow
topological view they require that one
entity in the set of chains usually a
root chain or root char and it's called
different things but one entity in the
set of chains has a view at all times of
what the other shards are what they're
doing it knows some sort of assignment
and it can reason about the security
properties of that system because it
knows what the topology is for obviously
we don't want to require this we want to
allow the topology to exist
amorphous ly as something that no chain
in the system no chain and the inter
chain has to know or reason about in
order to use the protocol safely that's
what we mean by locality and finally
this messaging protocol that we create
needs to be composable people need to be
able to reason about the security
properties of simply sending messages
and receiving messages just like the
reason about how you send and receive an
TCP IP and then using those properties
they need to be able to reason about the
gestalt properties of complex systems
which use those that book about us
that's what we mean by compose ability
to do this we've built a layered
protocol similar to the OSI model of IP
the first set of layers is called the
tau or I like to call it the tau of IVC
transport authentication and ordering
the tau of ibc handles getting data
physically using off chain processes we
call real ayres from one blockchain to
another or one ledger to another it
handles authentication creating a
standard for how different Ledger's can
authenticate summaries of each other's
consensus processes and use those
summaries to check that particular
packets were sent or received or not and
it handles ordering getting packets when
desired to the destination in order and
exactly in order I'll have to summarize
briefly over this protocol stack so I
think I will just use a picture consider
an IV see packets between two chains in
protocol as written at the moment we
have this entity called a module which
you can understand as being a
independent unit of execution running a
ledger so this will map to different
particular abstractions and different
block chains in the case of aetherium it
will map to a smart contract in the case
of the cosmos
decay we call it just a module in the
case of substrate I think it's also
called modules or packages or something
but the concept is the same
so a module on blockchain a will send an
IBC packet that's number one
it will head to number two the IBC
module which will interpret that packet
to determine how to route it the IBC
module will then store it in state the
consensus algorithm of blockchain a
that's three will then commit that
transaction commit to a state a state
route a relayer that's number five will
watch blockchain a figure out that an
outgoing packet has been sent then send
it on words in an incoming transaction
to blockchain B when the transaction is
accepted on blockchain B that's number
seven the packet will be routed to the
IVC module number eight on blockchain B
and the IBC module on blockchain B will
parse that packet decipher it determine
where it needs to go and send it on to
module B so all of the packets and
packet received time out handling all of
the basic primitives we build an IBC
followed this structure and the key part
that I would emphasize is that it's
quite generic the block chains and
modules need to have the ability to
verify each other state but otherwise
the trust model between these two
modules module a and module B is similar
to the trust model between two aetherium
smart contracts module a doesn't need to
reason about any of the other modules
running a blockchain a module B doesn't
need to reason about any of the other
modules running on watching B or
blockchain a they can simply once they
establish this secure communications
channel between each other
send and receive packets and reason
about this local system everything
contained on this diagram is sufficient
the understanding of it is sufficient to
reason about the security of IBC what
needs to come next we're calling the
application layer this is a little
analogous to ERC standards in the theory
and standards for call data we've built
IBC to be payload agnostic such that
when packets are real AIDS sent around
verified handled and timeouts by the
protocol the protocol implementations
don't need to
stand what the data in those packets
mean that only needs to be understood at
the edges needs to be understood by the
module sending or receiving these
packets dealing with how they should be
interpreted and what the semantics of
particular packet data are in order to
standardize this across the ecosystem
again in a non contentious fashion we
will need a set of application layer
packet encoding and semantic standards
some of these can probably build off
some of the work with ethereum is done
with ERC standards for called out of
between contracts we hope to collaborate
as much as possible
some of them will probably be different
opening up different use cases in things
like cross chain account abstraction
which someone recently submitted a Poe
request for to the IBC spec repository
which allows an account on one chain to
control the actions to send transactions
on behalf of an account on another chain
through IBC simple packets of course
like token transfer similar to a RC 20
the the semantics are a little bit
different because you're actually
transferring tokens between two block
chains so you need to account for supply
but call data is similar
more complex use cases we expect will
emerge over time including things that
look like sharding but are architectural
II a little different if you have
mutually comprehensible VMs on two
different chains you can relay code
between them through IBC and you could
use this two alongside a algorithm for
determining how to relay code over time
maybe some sort of load bouncing you
could use this to create protocols which
look like charting but they still have
this local security reasoning you only
need to reason about the block chains
you're directly talking to IB / IBC no
one needs to reason about the topology
of the whole network all of this work is
online you can find it at github comm
slash cosmos left ICS we recently
release released candidate for of the
IVC spec I would stress that it's not
done we are waiting on a few auditors to
get back to us and of course welcome any
feedback or questions trying to test
with several possible block chains which
aim to utilize IBC but it is definitely
in a state where you can read it and
understand
what we're trying to achieve with this
protocol why it fulfills that design
criteria of modularity locality and
composability and how you can get
involved and help so please do you found
a star thank you
[Applause]
you