►
Description
Brandon Lovejoy and Jonaed Iqbal sit down with Areg Hayrapetian, Matt Witherspoon and Guillaume Babin-Tremblay to discuss the functionality of Inter-Blockchain Communication (IBC) and Instant Finality (IF), how the protocols work together and how they benefit the Antelope ecosystem.
00:00:00 Start
00:00:04 Welcome to the Everything EOS podcast
00:01:14 Introduction to IBC
00:03:28 Introduction to Instant Finality
00:17:35 Trustless IBC
00:31:44 Instant Finality overview
00:39:55 Fundamental limits
00:42:01 Mathematical proofs
00:47:17 Security considerations
00:51:35 Third-party apps
00:58:50 IBC x Yield+ possibilities
01:01:34 Trustless verification
01:15:03 IBC vs Instant Finality
01:32:08 End
The EOS Network Foundation coordinates financial and non-financial support to encourage the growth and development of the EOS Network. We’re harnessing the power of decentralization to chart a coordinated future for the EOS Network as a force for positive global change.
// EOS Network Foundation //
https://www.eosnetwork.com
https://twitter.com/EosNFoundation
https://www.linkedin.com/company/eos-network-foundation
https://t.me/EOSNetworkFoundation
https://discord.gg/eos-network
info@eosnetwork.com
#EOS #Web3
A
A
B
C
Sure,
okay,
so
I
guess
IBC
stands
for
inter
blockchain
communication,
there's
there's
a
number
of
different
I
guess,
implementations
of
this
technology
and
they
they
might
mean
slightly
different
things
depending
on
the
concept.
So
here
as
we
as
we
as
it
as
it
pertains
to
us
in
the
Antelope
ecosystem,
we
refer
to
the
Antelope
IBC
as
essentially
like
this
ability
for
a
smart
contract
on
a
given
chain
to
prove
that
a
certain
action
took
place
on
a
on
another
blockchain
in
a
way
that
is
consistent
with
the
consensus
consensus
rules
of
that
other
blockchain.
C
D
Yeah
so
I
think
some
of
those
applications
that
people
are
most
familiar
with
is
just
moving
tokens
around
I
think
that's
like
the
most
permitted
form
of
Legacy
that
people
think
about
and
we're
talking
about.
Obviously
we're
talking
about
something
a
lot
more
foundational
in
general
than
that
we're
talking
about
just
the
ability
for
two
contracts
for
two
pieces
of
software
to
communicate,
even
though
they
live
on
different
blockchains
one
application
bin.
D
D
Initially,
the
block
is
just
really
a
proposal,
and
it's
not
yet
final:
it's
not
irreversible,
meaning
it
could
be
forked
out
and
replaced
by
some
other
block.
Instead,
finality
is
when
you
can
actually
trust
that
this
that
the
block
will
remain.
It
won't
be
replaced
by
something
else,
and
so
the
side
effects
of
that
block.
D
So
basically,
how
long
do
you
typically
wait
from
when
you
send
the
transaction
to
when
the
transactions
included
in
the
block,
and
the
block
is
final,
because
that
you
know
that
that's
finality
is
what
you
care
about.
Ultimately,
that's
that
latency
is
what's
really
important,
so
for
Antelope
has
exists
today.
D
The
algorithm
that
we
use
is
foreign.
It's
such
that
it
depends
on
the
number
of
block
producers,
so
on
EOS,
for
example,
there's
21
block
producers.
It
depends
on
that
number
for
how
long
you
have
to
wait.
How
many
blocks
you
have
to
wait.
Therefore,
how
long
you
have
to
wait
to
reach
finality,
and
so
on,
esp21
block
producers.
It
takes
three
minutes
if
you
were
to
double
that
it
would
take
six
minutes.
D
So
instant
finality
is
a
new
consensus
algorithm
for
finality
that
fixes
that
issue,
and
it
does
two
things
one.
It
makes
the
time
you
take
very
weekly
depending
on
the
number
of
black
producers.
Basically
it's
more
or
less
irrelevant
and
two.
It
just
reduces
that
number
way
down
from
three
minutes
to
basically
low
set
low
single
digit
seconds.
It
depends
on
the
how
distributed
network
is,
but
it
basically
starts
becoming
low
enough
that
it
depends
on
how
quickly
messages
can
be
sent
across
the
internet.
D
C
There's
there's
always
a
window
of
time
where
that
transaction
could
be
reversed
or
it
could
be.
You
know
like
forked
out
and
would
have
to
be
retried
again,
so
that
introduces
additional
risks
like
to
the
transaction,
whatever
the
transaction,
maybe
there's
a
there's
a
window
of
time
during
which
something
can
happen
doesn't
happen
necessarily
very
often,
but
it
could
and
that
could
have
consequences
so
earlier,
we're
discussing
the
concept
of
IBC.
C
This
is
this
is
personally
what
led
me
to
these
questions
about
instant
finality
when
you're
doing
IBC,
for
instance,
if
you're
going
to
be
locking
tokens
on
a
given
chain
and
minting
other
tokens
on
another
chain
through
this
protocol.
Now
there
is
a
like
you
have
to
ensure
that
the
state
on
these
two
chains
remains
consistent
in
an
atomic
Manner
and
academic
matters.
So
if
you
have
a
long
time
the
finality
then
like
you,
have
to
wait
longer
or
you
risk
having
inconsistencies
and
that's
that
that
of
course
impacts
the
user.
D
B
B
C
I
think
there's
there's
a
potential
to
be
impacted
by
blockchain,
Technologies
and
smart
contracts.
However,
in
order
for
this
to
to
happen,
these
systems
have
to
be
built
with
very
solid
foundational
blocks
and
with
with
tremendous
capability
and
in
terms
of
scale
in
terms
of
throughput
in
terms
of
load
and
and
security
and
there's
the
way
to
make
it
scale
in
many.
C
Many
ways
has
to
do
with
the
ability
of
these
chains
to
communicate
with
each
other
and
to
essentially
allow
for
whatever
Innovation,
whatever
different
governance
mechanism
to
to
be
applied
to
different
contexts
or
to
be
experimented
with,
but
still
having
a
I
guess
like
a
common
interface,
a
common
way
to
exchange
information
and
to
distribute
applications
across
these
systems.
So
for
me,
like
these,
two
things
are
like
IBC
and
instant
finality.
C
D
D
Other
possibilities
so
I'm
thinking,
for
example,
games,
depend,
or
you
know,
games
I
think
is
probably
a
good
application,
obviously
not
fast
enough
for
certain
types
of
communication
and
games
where
you're
talking
about
milliseconds,
but
once
you
get
it
down
to
seconds
like
there's,
maybe
certain
turn-based
games
or
something
like
that,
where
that's
fast
enough
that
it's
no
longer
a
barrier
to
using
the
blockchain,
for
example,
to
to
do
that
with
this
the
finality.
So
that's
that's
one
aspect
of
it
that
excites
me.
D
The
other
aspect
is
very
behind
the
scenes
that
people
it
was
not
visible
to
the
user,
but
I
care
about
a
lot
which
is
with
this.
It's
the
finality
work
as
part
of
the
RFP
we've
created
requirements
to
ensure
it
has
certain
properties
and
also
to
have,
as
part
of
the
deliverable
proofs
mathematical
proofs
that
it
meets
those
achieve
those
properties
which
I
think
is
very
important
when
we're
talking
about
a
consensus
algorithm-
and
you
know,
antelope
in
his
past-
has
has
well
it
has.
D
Its
current
consists
algorithm
that
achieves
certain
properties,
but
it
doesn't
have
that
rigor
that
I'd
like
to
see
so
we're
kind
of
stepping
it
up
and
ensuring
we
meet
that
that
mathematical
rigor,
that
one
would
expect
from
something
as
fundamental
as
a
consensus
algorithm
for
IPC.
It's
really
about
scale.
It's
not
only
about
scale,
so
I
guess
two
things
there
too
scale
is
a
multi-faceted
thing.
It's
not
just
IBC
I
think,
there's
lots
of
ways.
D
We
can
approach
it
to
try
to
horizontally
scale,
both
in
terms
of
storage
costs
and
in
terms
of
just
throughput
transactions
per
second,
but
certainly
I.
Think
IBC
is
a
critical
component
of
that
one
of
the
significant
options
we
need
to
consider
for
how
we
horizontally
scale
and
achieve
much
larger
numbers
for
aggregate
throughput
that
a
lot
of
people
would
like
to
see
and
maybe
have
heard
in
the
past.
D
Ibc's
been
talked
about
in
the
eospace
for
a
long
while
now
and
we're
finally
actually
seeing
it
come.
You
know
to
fruition
soon.
So
that's
really
exciting.
I
think
it's
just
the
beginning.
Stages
like
this
is
just
the
building
blocks
of
simple
message.
Passing
I.
Think
there's
so
much
more
that
needs
to
be
built
on
top
and
to
make
it
easier
for
an
application
to
actually
leverage
a
multi-blockchain
platform
and
and
scale
that
way,
but
already
a
lot
can
be
enabled
with
what's
with
what's
coming
with
IBC
as
part
of
this
initial
deliverable.
D
The
other
aspect
as
well
is
even
Beyond
scale.
You
know
it's
not
going
to
be
as
single
blockchain
rules
of
all
environment
right
there'll
be
blockchains
that
specialize
in
different
niches
and
different
governance,
experiments
and
I
think
it's
it's
important
to
be
able
to
have
these
communicate
together
and
kind
of
act
as
one
whole.
Cohesive
ecosystem,
so
IBC
enables
that
to
be
on
just
stale.
E
Yeah
there
is
yeah.
There
is
something
there
that
to
continue
on
a
little
bit
of
part
of
your
thought.
There
are
really
excites
me
specifically
about
the
the
IBC
aspect
of
of
antelope.
Is
that
when,
when
a
protocol
was
designed
like
five
years
ago,
like
we,
the
the
protocol
was
designed
with
this,
this
idea
that
you
could
do
light
validation
of
it
to
the
to
the
to
the
smallness
of
like
doing
it
inside
of
a
of
an
antelope
contract
and
I.
E
C
Yeah,
maybe
yeah,
just
just
if
I,
if
you
don't
mind
I'd
like
to
add
a
quick
note
there
as
I
as
I,
started
working
on
on
IBC
at
some
point
at
some
point
like
I
I
wanted
it
I
needed
it.
So
I
was
like
okay,
like
let's,
let's
work
on
that,
let's
get
it
done.
That
was
very
obvious
that
the
design
had
the
design
of
antelope
like
yes,
I
all
the
time.
A
A
C
Yeah
I
mean
I,
guess
the
the
term
trustless
the
way
the
way
I
look
at
it
is.
It
does
not
require
trusting
any
additional
entities
that
you
don't
already
trust
in
the
in
the
process.
So
it's
it's
essentially
you're
using
a
blockchain,
of
course,
if
there's
a
consensus
mechanism
on
that
blockchain
in
in
the
case
of
antelope,
like
systems,
you
have
a
point
at
which
the
consensus
rules
are
able
to
tell
anyone
who's
watching
that
the
specific
block
is
final
or
is
irreversible.
C
C
Now
there
is
a
like
locked
State
between
these
two
chains,
where
essentially
like
there
should
be
a
one-to-one
equivalency
between
the
amounts
of
tokens
that
have
been
locked
on
on
EOS
versus
the
amounts
of
tokens
that
have
been
minted
on
wax.
So
as
this,
let's
call
it
like
a
dual
State
exists.
You
need
to
trust
the
governance
mechanism
of
both
chains
simultaneously,
because
now
there's
there's
a
potential
Divergence
in
that
state.
C
That
could
depend
on
like
the
governance
rules
or
the
processes
or
the
system
contracts
or
other
other
contracts,
the
token
contract
itself
that
could
potentially
affect
this,
this
joint
state.
So
it's
the
way
I
I
like
to
Define
it
is.
It
does
not
require
additional
trust
in
entities
that
are
already
trusted
implicitly
by
performing
that
action.
A
D
Yeah
I
I,
basically
just
kind
of
agree
with
what
Yom
says
that
that's
the
way
I
would
look
at
this
word.
Trustless
I've
had
some
objections.
It's
the
word
trustless,
mostly
pedantic,
but
I
think
it's
work.
There
are
some
that
is
is
worth
pointing
out,
as
guillem
already
has
I
won't
restate
it
is
that
there's
always
something
you
trust.
D
It's
important
to
understand
what
that
is,
because
there
are
ramifications
there
in
extreme
situations.
You
can't
just
you
know,
people
say
just
trust
the
math,
but
it's
and
first
of
all,
you
are
trusting
that
you
know.
Have
you
validated
the
cryptography
right
like
there
could
be
flaws
there,
but,
more
importantly,
there
are
other
things
there.
So,
for
example,
the
math
might
tell
you
that
this
coming
back
to
finality
that
it's
it's
Byzantine
fault,
tolerant
I
mean
it
could
tolerate
some
number
of
Byzantine
some
number
of
the
actors
misbehaving.
D
But
nothing
says
you
can't
have
more
than
those
actors
misbehaving
and
then,
if
you
want
to,
if
you
could
dig
in
deeper
as
to
why
you
believe,
that's
not
going
to
happen,
there's
actually
an
economic
argument
for
that.
It's
not
just
like
pure
math,
as
you
know,
mentioned,
with
IBC
the
there's
lots
of
points
where
you
could
potentially
compromise
the
Integrity
of
the
messages
being
sent
back
and
forth
so
like
if
you're
talking
with
the
low
trust
chain,
but
your
contract
State
depends
on
the
state
of
the
other
chain.
D
If
those
chains
block
producers,
for
example,
are
compromised
and
change
their
token
contract
that
fundamentally
changes.
You
know
the
state
like
they
could.
They
could
just
lie
and
and
tell
you
something
happened
on
that
chain
that
didn't
happen.
So
that
has
to
be
considered,
especially
when
you
start
having
these
intricate
interconnected
mesh
of
dependencies
across
multiple
chains.
B
C
I
can
I
can
kind
of
bind
on
that
so
I
guess
I,
guess
I
believe
that
the
term
was
coined
by
the
cosmos
guys
when
they
released
their
white
paper.
I,
believe
that
was
in
2015
or
something
yeah
a
lot
yeah
around
that
time.
So
I
believe
they
came
up
with
the
IBC
inter
blockchain
communication
moniker,
which
has
been
reused,
I
guess
across
multiple
ecosystems,
including
Antelope
I.
Remember
personally,
like
the
first
time
I
heard
about
that.
C
Was
you
know
by
Dan
Larry
Murray
mentioned
it
I
think
in
in
some
some
some
posts
somewhere
and
it's
I
mean
some.
Some
people
might
disagree.
I
had
discussions
on
Twitter
with
some
of
the
cosmos
guys
that
seem
to
to
disagree.
But
to
me
it's
a
very
generic
term,
I
guess
that
that
has
been
around
for
for
for
quite
a
while.
C
That's
how
the
the
The
Interchange
communication
was
handled.
So
you
would
have.
You
would
have
a
group
of
people
that
were
essentially
running
the
client
software
of
two
different
blockchains,
and
then
they
would
observe
what
was
happening
on
blockchain
a
and
when
they
needed
to
replicate
this
on
on
blockchain
B.
They
would
do
like
some
sort
of
a
multi-sig,
and
they
would
like
some
threshold
like
like
three
out
of
five.
Four
out
of
seven
of
these
custodians
would
essentially
sign
a
transaction
that
would
like
mimic
the
action
that
you
that
you
wanted.
C
Over
the
last,
let's
say
like
12
to
18
months,
probably
before
that
as
well,
but
especially
in
the
last
year
year
and
a
half
there's
been
several
very
high
profile
cases
of
like
trusted,
oracles
Oracle
setups
that
failed
in
in
the
most
spectacular
ways
where
hundreds
of
millions
of
dollars
of
of
luck
tokens
were
basically
stolen.
So
it's
it's!
It's
quite
important,
I
think
to
do
things
right
and
to
go
the
the
long
and
hard
and
difficult
Road
of
you
know
like
doing
it.
B
A
A
C
C
This
is
how
they
they
essentially
work
where,
if
you,
if
you
look
again
taking
the
example
from
from
before,
if
you
lock
some
EOS
on
yes
and
with
the
intent
of
minting
some
rapias
on
wax,
what
you're
doing
is
you're
sending
these
tokens?
These
yes
tokens
to
the
wrap,
lock
token
contract
on
on
the
wrap,
lock
contract
on
the
yes,
that
generates
a
proof
that
now
can
be
submitted
to
the
IBC
smart
contract
on
wax
and
can
can
can
be
used
as
the
condition
to
Mint
these
wrap
tokens.
C
So
if
I'm
able
to
submit
a
valid
proof
that
I've
locked
tokens
on
the
es
side,
if
I'm
able
to
submit
that
to
the
wax
side,
the
equivalent
amount
of
token
is
minted
and
of
course,
there's
a
replay
protection
mechanism
so
that
you
can't
prove
the
same
thing
twice.
For
example,
and
the
reverse
process
applies
when,
when
you
want
to
redeem
the
original
asset
back
on
yes,
so
you
take
these
rep
tokens
on
wax,
you
burn
them.
C
You
submit
the
proof
that
you
burn
these
assets
like
burn,
is
a
retire
in
in
the
in
the
Antelope
terminology.
So
you
retire
these
tokens,
and
then
you
submit
that
proof
back
to
the
the
the
on
the
es
side
that
will
now
unlock
these
tokens
that
were
locked
previously
and
like
send
them
or
make
them
claimable
by
you.
Essentially.
C
And
that's
that's
just
that's
just
one
example
by
the
way,
like
of
of
what
can
be
done
as
we
as
we
entered
that
earlier,
there's
there's
many
other
construct
that
can
be
built
on
top
of
IBC
to
like,
like
have
like
multiple
chain
governance
to
have.
You
know
like
a
staking
resources
on
the
main
chain.
Having
like,
like
virtual
resources,
allocated
on
side
chains,
you
can
build
any
sort
of
proving
mechanism.
C
B
C
Yeah
yeah,
I,
guess
hard
to
say
right,
I
mean
I
mean
yeah,
it's
obviously
obviously
like
there's.
This
is
a
space
that
is
evolving
very,
very
fast,
like
there's
new
new
project
coming
out
new
projects
coming
out
all
the
time,
so
it's
really
hard
to
stay
to
stay
up
to
date
with
with
everything
that's
happening
everywhere.
C
However,
the
when
it
comes
to,
let's
say
state
of
the
art
consensus
mechanisms
right
now,
there's
the
there's
there's
been
quite
a
bit
of
research.
That's
been
done,
I
mean,
like
people
probably
have
heard,
of
Materia
M
2.0
Casper
there's
also.
We
spoke
about
Cosmos
a
little
bit
earlier.
It
has
the
tender
mint
consensus
model.
So
these
are.
These
are
I,
guess
I,
guess
like
previous
generation,
compared
to
what
we're
doing.
If
you
look
at
the
at
the
time
that
these
algorithms
were
formulated,
I
think
it
was
around
like
2014
2015.
C
there's
it
takes.
It
takes
a
while
before,
of
course,
some
some,
some
crazy,
nerds
and
and
and
some
University
come
up
with
these
things
and
eventually
like
it,
it
gets
tested
and
I
guess
you
know
like
researched
and
tried
out
before
it
can
make
its
way
into
into
a
blockchain,
so
it
took
in
in
both
of
these
cases
these
these
these
algorithms
were
designed
a
long
time
before
they
actually
became
used
in
production
and
and
similarly
we,
the
one
that
we
selected
on
our
as
as
we
were
approaching.
C
This
is
quite
interesting
compared
to
what
already
exists.
There's
there's
some
very
good
trade-offs
that
can
be
made,
there's
some
a
degree
of
flexibility
and
a
degree
of
I
guess
yeah,
like
parameterization
in
that
that
consensus
algorithm,
that
is
very,
very
exciting,
like
it
really
opens
a
lot
of
possibilities
so
in
in
a
way
I
feel
like
we
are
at
The
Cutting
Edge
of
this
of
this
I
guess,
research
I'm,
not
aware
of
anyone
else,
having
deployed
or
even
working
on,
Hot
Stuff
consensus
for
a
blockchain
project.
C
Were
it
changed,
names
I
think
it
was
called
DM
for
a
while,
but
that
also
got
got
shelled
at
some
point.
So
as
far
as
I
know,
there's
no
one
else.
Who's
who's
been
working
with
this,
but
I
think
we
it
is.
It
is
an
opportunity
in
a
like
okay,
I
guess,
like
a
potential
source
for
renewal
in
in
interest
of
of
now
Antelope.
As
we
start
rolling
it
out,
I
think
it
will.
It
will
have
it's
it's
it's
moment
in
the
in
the
in
the
spotlight.
D
I'll
just
add
that
so
there's
there's
a
whole
there's
a
lot
of
PFT
algorithms
out
there
used
by
their
different
blockchains,
I,
think
ones
that
are
most
relevant
and
interesting.
Look
at
is
Casper
and
tendermint,
and
then
now
hot
stuff,
which
is
what
we're
basing
the
algorithm
that
antelope
will
be
using
for
instant
finality,
and
these
are
all
I
mean
ultimately
Trace
them
all
back
to
classical
bft
algorithms.
This
stuff
was
very
old,
but
has
been
improved
on
over
the
years.
D
Most
recently
takes
the
blockchain
focusing
on
you,
know,
liveness
and
performance,
and
things
like
that.
You
also
this.
This
Cutting
Edge
stuff
I
mean
gam
and
I
were
talking
about
advances
on
top
of
hot
stuff
and
whether
we
can
squeeze
more,
you
know
squeeze
a
better
time
out
of
it,
but
there's
also
a
concern
of
getting
two
latest
and
greatest
then
Cutting
Edge,
and
whether
you
trust
the
the
safety
of
it.
You
know
how
how
much
validation
has
been
done.
D
One
thing
I
would
point
out
without
going
into
too
much
of
the
details
is
two
properties
that
I
think
are
very
interesting
compared
to
what
else
is
out
there
or
what's
commonly
out
there.
Those
two
properties
are
linearity
and
optimistic
responsiveness.
So
when
it
comes
to
linearity
this
is
this
leads
to
one
of
the
other
deliverables
as
part
of
the
RFP,
which
is
BLS
aggregate
signatures.
Linearity.
D
Is
this
idea
of
reducing
the
amount
of
communication
that
you
need
between
the
various
consensus
participants
to
to
scale
linearly
with
the
number
of
participants
rather
than
what
is
often
done?
Is
quadratically
scaling
debt
and
it
does
this
using
a
cryptographic
scheme
that
allows
you
to
take
different,
different
shards
I?
D
Guess
you
could
say
of
signatures
and
and
combine
them
together
to
form
the
signature
which
represents
one
signature
from
this
kind
of
aggregate
public
key,
which
is
the
aggregation
of
all
the
different
participants,
public
keys,
and
that
is
the
the
magic
basically
of
taking
this
from
quadratic
ceiling
to
linear
scaling,
which
is
important
in
terms
of
increasing
the
the
number
of
participants
for
the
sake
of
decentralization,
for
example,
the
other,
the
other
big
important
change
is
or
this
property.
That's
really
desirable,
optimistic
responsiveness.
D
So,
especially
if
you
look
at
say,
tendermint
and
and
Cosmos,
you
can
kind
of
view
them
from
the
lens
of
Hot.
Stuff
hot
stuff
has
a
three
round
a
three-phase
consensus
model,
whereas
those
two
are
two
phases.
So
you
could
view
that
as
a
negative,
where
you're
adding
an
extra
phase
more
latency,
but
on
the
other
hand
it
does
get
you
this
benefit
of
optimistic
responsiveness
where
you're
not
awaiting
an
arbitrary
amount
of
time
to
get
to
get
to
listen
from
enough
participants
to
feel
like
you're.
D
D
B
A
All
right,
yeah,
I,
just
love
the
phrase,
optimistic
responsiveness,
but
I
couldn't
tell
you
like
someone
needs
to
look
that.
Look
that
up
and
report
back
to
me
so
I
can
all
right.
You
hinted
that
we're
getting
close
to
fundamental
limits,
and
this
is
something
that
that
came
up
in
our
conversation.
All
right.
Do
you
care
to
add
anything
to
that.
D
Yeah
I
mean
it's
so
part
of
the
optimistic
responsiveness
is
to
not
have
these
arbitrary
restrictions
on
time.
I
mean
even
even
something
as
Jim
and
I
were
talking
about
this
just
recently
about
like
chain
Hot
Stuff
versus
basic
hot
stuff,
and
how
do
we
get
the
best
of
both
worlds
and
one
thing
with
chain
house
stuff?
D
If
you,
if
you
do
it
sort
of
naively,
is
you're
putting
each
confirmation
at
the
level
of
a
block-
and
this
reminds
us
of
the
current
reminds
me
of
the
current
algorithm
of
EOS
and
the
reason
why
it
scales
with
the
number
of
producers,
the
time
to
finally
scales
with
number
of
producers,
is
because
you're
arbitrarily
limiting
it
to
one
confirmation
like
from
one
VP
per
block,
so
every
half
second
one
BP
can
provide
one
confirmation
with
linearity.
You
can
have
and
chain
house
that's
naively
applied
to
enough
stuff.
D
You
can
have
all
BPS
provide
their
confirmation
in
what's
called
a
quorum
certificate
per
block,
but
even
that's
maybe
not
fast
enough,
because
you
need
three
phases
of
this
stuff.
So,
instead
of
weighing
three
blocks,
it'd
be
nice.
If
you
could
just
go
as
fast
as
Network
conditions
allow
and
maybe
get
three
blocks
within
less
than
half
a
second
of
course.
To
actually
do
that,
I
mean
you
could
do
that
if
you
have
a
a
network,
that's
closer
together
like
a
local
network
or
maybe
a
broader
Network
that
has
fast
links
between
each
other.
D
But
when
we're
talking
about
Global,
decentralized
Network,
you
know
with
nodes
all
over
the
world
and
lots
of
hops
and
processing
along
the
way.
You
start
starts
becoming
very
difficult
to
have
a
sub
second
time
to
finality,
just
because
of
the
time
it
takes
to
send
the
messages
from
one
computer
to
the
other
validate
and
send-
and
you
know
just
fundamental
computation
and
network
speed
times
may
become
the
bottleneck
at
some
point.
D
We
so
there
are
as
part
of
what
we
want
to
achieve
with
this
new
finality
algorithm
as
part
of
what's
required
in
the
RFP
requirements,
was
to
ensure
that
we
can
provide
cheap
proofs
for
finality.
So
as
it
relates
to
now
actually
IBC
so
there's
a
connection
there
IBC
as
it
exists
now
and
it
works.
It
works
with
the
existing
algorithm.
D
The
existing
finality
algorithm
that
that
antelope
has,
but
but
it's
dependent
on
the
consensus
algorithm
view.
So
when
we
change
the
consensus
algorithm
to
use
is
the
finality.
The
IBC
contracts
will
have
to
be
updated
to
use
that,
and
so
we
wanted
to
make
sure
we
preserve.
You
know
we
talked
about
the
design,
so
that
was
meant
for
IBC.
D
So
those
are
the
kinds
of
things
we
talk
about.
When
we
talk
about
cryptographic,
cryptographic.
Proof
of
finality
of
a
block
that
is
smart
contract
can
validate
another
cryptographic
proof
related
to.
That
is
what
happens
so
we
talk
about
Byzantine,
fault,
tolerance
and
and
how
there's
certain
number
of
basically
faults
you
could
tolerate
before
where
nothing
goes
wrong.
D
But
what,
if
it
goes
beyond
that
point,
which
it
theoretically
could
and
the
only
reason
it
shouldn't,
is
because
you've
designed
economic
incentives
to
make
that
unlikely
to
happen,
or
you
know
make
it
financially
disadvantageous
to
do
so,
but
in
order
to
actually
ensure
that
you
need
a
mechanism
to
enforce
against
bad
behavior
and
part
of
that
mechanism
would
be
cryptographic
proof.
So
someone,
let's
say
someone.
You
know
worst
case
scenario,
they've
been
defrauded
they've
they've
set
of
you
know,
two-thirds
or
more
of
block
producers,
for
example.
This
you
know
worst
case
scenario.
D
D
Let's
say
there
are
light
clients
validating
the
proof
so
that
they
believe
that
this
chain
is
final,
so
they
can
rely
on
the
side
effects
of
that.
How
can
that
client
get
sufficient
data
from
that
process
such
that
later?
If
they
discover
that
was
not
the
canonical
change,
the
real
chain
is
somewhere
over
here.
I.
Don't
have
my
tokens
on
that
on
that
version
of
the
chain.
How
could
then
they
take
this
data
and
the
data
in
the
public
chain
and
use
it
to
construct
a
proof?
D
So
that's
another
side
of
cryptographic,
proofs
that
we're
requiring
we're
thinking
about
ahead
of
time
and
actually
requiring,
as
part
of
these
levels,
to
design
for
that
and
provide
reference
code
to
to
show
how
that
could
all
work
in
smart
contracts
and
validate
it
on
the
mathematical
proof.
Side
is
sort
of
like
okay,
but
how
do
we
know
these
properties
will
like
vigorously
mathematics
with
mathematical
rigor?
How
do
we
show
it's
safe?
How
do
we
show
this
protocol's
light
as
the
liveness
properties,
and
we
have
that
accountability
thing?
C
I
think
that's
that's
very,
very
thorough
I
mean
you
could
look
at.
You
could
look
at
the
mathematical
proofs
as
the
I
guess,
like
foundational
work
at
the
design
level,
where
we
we
want
to
make
sure
that
certain
properties
Eric
named
them
safety,
liveness
accountability
are
demonstratable
demonstrable.
At
any
point,
you
can
verify
that
these
property
owls,
if
initial
assumptions
are
followed
and
then
from
there
when
you,
when
you
complete
the
system
when
it's
completely
implemented.
C
This
is
essentially
applied
to
this
is
this
is
measured
and
verified
through
applied
cryptography,
so
these
these
proofs
are
essentially
like
that
that
the
cryptographic
schemes
that
we
use
are
essentially
conform
to
to
these
proofs
and
they
they
allow
to
to
demonstrate
that
these
things
that
these
properties
are
upheld
and
maintained.
At
any
point.
A
All
right
give
him
anything
that
you'd
like
to
add
as
far
as
some
like
key
differentiating
features,
stuff
you've
been
working
on.
One
thing
that
occurs
to
me
is
like
the
security
considerations
that
you
were
kind
of
touching
on
with
the
cryptographic
proofs
emits
so
I'm
just
I.
Just
wonder
how
much
time
you
spend
thinking
about
how
to
attack
what
you're
building
versus
just
building
what
you
want.
You
know
it's
like.
How
often
do
you
think
of
some
solution
and
you're
like
this
is
brilliant
and
then
you're
like?
Oh,
but
you
know.
B
C
C
That
creates
a
a
scenario
where
no
progress
like
no
no
finality
progress
can
be
achieved
until
that
situation
is
resolved,
but
a
an
IBC
system
would
still
have
to
be
able
to
recover
from
from
a
situation
like
that.
So
originally
the
first,
the
first
iteration
that
we
had
didn't
take
that
into
account
as
an
edge
case
and
Eric
pointed
it
out.
What
happens
if
you
know
and
we're
like?
C
Oh
yeah,
so
we
need
to
change
that
and
to
take
that
into
account
and
there's
there's
definitely
some
it's
it's
a
it's
an
iterative
process
that
that
requires
also
I
guess,
like
constant
vigilance
as
upgrades
are
performed
and
as
things
change
here
and
there,
because
we
we
want
to
make
sure
that
we
always
respect
consensus
algorithms
of
multiple
chains
as
they
are
as
they
as
they
evolve
over
time.
So
it's
definitely
there's.
There's
definitely.
E
C
Lot
of
I
guess
factors
to
take
into
consideration,
and
it's
the
the
good
thing
is
well
I
mean
so
far.
We've
been
we've
been
through.
Multiple
audits
from
multiple
Auditors
and
everything
everything
is
is
is
great,
but
yeah
like
it's.
It's
it's
a
constant
process
as
you're
building
these
things,
you
have
to
always
think.
Okay,
what
happens
if
the
proofs
are
constructed
and
that
in
this
way,
can
is
that
gonna
like
like
go
through
or
is
that
going
to
be
stopped
by
the
checks
that
we
have
in
place?
C
C
B
Later
you
know
so
going
back
to
something
earlier.
What's
the
timeline
for
third-party
developers
to
build
on
this,
like
what
do
you
see
them?
What
are
they
going
to
start
developing
and,
as
you
know,
the
first
applications
aren't
always
the
most
complex,
but
what
are
they
going
to
build
towards
and
what
kind
of
applications
will
you?
All
of
you
be
excited
to
see.
C
Well,
I
mean
some
people
already
started.
We
we've
been
as
as
we're
progressing
to
the
IBC
milestones,
as
as
code
is
reviewed
and
code
is,
is
released,
some
of
the
I
guess
I
can
satellites
and
various
infrastructure.
That's
related
to
IBC
is
already
public
and
there's
already
some
themes
that
started
looking
into
this
and
reaching
out
and
asking
to
some
some
guidance
to
start
building.
C
So
essentially,
at
that
moment
we
also
will
release
the
the
source
code
and
then
the
entire
solution
can
now
be
can,
like
anyone
can
start
looking
into
this
and
and
and
build
on
top
of
it.
There's
already
like
I
said
some
people
that
are
already
building
various
things:
I'm,
not
gonna,
I'm,
not
gonna,
say
who,
because
they
they
didn't,
grant
me
that
it
was.
It
was
told
in
confidence,
but
but
it's
it's
it's
it's
doable
now
and
I.
C
Think
I
think
it
will
only
accelerate,
as
we
releases
the
documentation
as
we
release
the
entirety
of
the
code
and
as
people
start
spreading.
The
words
I
think
just
like
just
like
a
lot
of
the
other
things
in
this
ecosystem,
I
mean
there's,
there's
a
first,
a
a
phase
of
you
know
like
Discovery,
for
everyone
to
okay.
Now
this
is
available.
How
does
that
work
like
how
that
can?
How
can
I
integrate
that
in
my
application?
C
But
we
we
know
a
lot
of
people
are
definitely
very
excited
a
lot
of
depths
I've
reached
out
over
the
last
last
few
months
and
they
definitely
have
big
plans
to
build
on
top
of
it.
So
so
we're
expecting
this
to
start
like
slowly
but
start
ramping
up
quite
quite
quite
soon.
This
is
this
is
where,
in
the
last
print
so.
D
Again,
you
mentioned
something
that
I
think
it's
worth
pointing
out
here,
so
we're
talking
about
how
right
now.
So
it's
already
on
test
net,
you
know,
but
for
for
maidenet.
Currently
it's
in
the
process
of
waiting
on
BPS
to
approve
multi-six,
but
that's
actually
just
for
really
a
nice
name
and
kind
of
having
blessed
contracts
yeah.
The
reality
is
that
this
is
maybe
you
could
talk
about
that
a
little
bit
about
like
different
layers,
we
kind
of
mentioned
earlier,
but
also
the
the
fact
that
you
don't
really
need
permission
to
build
on
it
once
it's.
C
Of
course,
there's
there's
this
the
bridge
contract
itself,
that
that
serves
to
prove
the
actions,
as
we
were
saying
earlier
and
then
there's
a
wrap,
wrap
token
contracts
that
are
used
to
represent
tokens
that
are
locked
on
a
certain
chain
and
made
available
to
to
a
different
chain.
So
when
we
like
most
of
the
use
cases
that
go
around
these
wrap
block,
tokens
have
to
do
with
liquidity.
C
So
there's
there's
an
incentive,
if
you
want
to
for
for
people
to
use
the
same
contracts
to
use
the
same
representation
of
these
rep
tokens
so
that
you
don't
end
up
with
several
representations
of
the
same
thing.
The
same
thing
that
could
be
like
different.
You
know,
like
maybe
maybe
like
there's,
there's
one
contract
here,
one
contract
there
and
and
and
so
on
and
so
forth-
that
have
that
all
represent
like
a
raptios
or
a
wrapped
usdt,
but
they're
not
the
same.
C
So
it
makes
it
complicated
for
applications
on
the
other
chain
to
support
multiple
competing
quote-quote
proposals.
So
for
in
order
to
address
that,
we,
as
we
discussed
with
the
Coalition,
we
said
we
will
have-
these
quote-
quote
official
contracts
that
that
that
that
we
will
that
the
the
chains
will
promote.
That
will
be
essentially
under
the
the
control
of
of
the
network
of
the
block
producers.
That
will
be
like
the
the
the
ones
that
are
quote
supported
and
that
people
are
invited
to
to
focus
their
attention
on.
But
it
is
not.
C
It
is
not
a
requirement
for
this
technology
to
work.
Anyone
can
essentially
take
the
code
just
like
just
like
right
now:
people
don't
create
tokens
on
the
official
esiado
token
account
they
do
take
a
copy
of
the
yes
Iota
token
code.
They
copy
it
to
their
own
account
and
then
they
issue
their
tokens
there.
So
it's
the
same
mechanism
if
he
wants
the
same
logic,
but
it
does
not
reside
in
the
same
the
same
space.
So
we're
we're
giving
the
same
flexibility
basically
through
that.
C
True
that
the
release
of
that
software,
where
anyone
can
take,
for
example,
the
wrap
token
and
wrap
lock
contracts
and
deploy
them
on
any
network
and
make
their
own
tokens
available
for
for
interchange
transfers.
And
it's
a
it's.
It's
important
that
to
to
to
highlight
that,
because
our
goal
is
not
to
close
the
system
and
making
sure
that
only
like
the
official
versions
are
supported,
we're
doing
that
to
help
concentrate
liquidity.
But
it's
not
it's
by
no
mean
a
requirement
to
use
the
official
versions.
C
As
a
matter
of
fact,
there's
there's
potential
arguments
to
be
made
in
favor
of
using
other
other
versions.
If,
for
example,
someone
was
to
build
a
liquidity
aggregation
mechanism
that
would
Leverage
The
Yield
plus
program,
for
example,
or
things
along
those
lines
so
in
in
that
case,
this
is
not
going
to
be
done
in
the
official
versions,
but
someone
could
could
create
a
product
that
would
essentially
like
offer
this
additional
yield
to
depositors
to
stakers
using
their
own
version
of
the
of
the
of
these
token
contracts.
So
if
that
makes
sense,.
A
C
As
we
call
it
like
total
value
luck,
it
removes
tokens
from
the
the
the
exchanges
it
removes
tokens
from
the
float
of
the
market,
so
these
tokens
typically
are
staked
for
longer
periods,
so
it
it.
We've
done
quite
a
bit
of
research
that
that
that
that
that
has
has
been
published
in
the
Yale
plus
blue
paper
and
in
the
monthly
reports
for
the
yield
plus
program
that
that
highlight
these.
C
The
relationship
between
market
cap
and
tvl
between
chains
like
if,
if
tvl,
goes
up
up
to
a
certain
point,
it
does
also
bring
market
cap
up
as
well.
There's
there's
like
diminishing
return
at
a
certain
level,
but
there's
there's
definitely
a
sweet
spot
that
the
yield
plus
program
is
trying
to
to
identify.
C
Essentially
so
so
so
here
with
the
with
the
context
of
IBC
team,
one
of
the
one
of
the
interesting
question
becomes:
if
we,
if
we
are
able
to
essentially
attract
other,
let's
call
them
like
not
necessarily
stable
coins,
but
let's
call
them
like
high
liquidity
tokens
and
we're
we're
able
to
lock
them
on
on
Antelope
chains.
We
are
contributing
to
that
tvl
and
we're
contributing
to
the
market.
C
B
C
Yeah,
it's
a
very
good
question
so
essentially
like
the
the
the
the
smart
contracts
on
on
a
given
chain
will
verify
the
proof
so
essentially
like
that
proof
that
is
submitted
to
that
smart
contract
will
be
verified,
so
it
doesn't
really
matter
in
terms
of
like,
like
Safety
and
Security,
where
that
proof
comes
from
how
it's
been
generated.
We
just
we
just
have
the
smart
contract
that
will
essentially
verify
a
number
of
of
of
things
with
that
proof
and
at
the
end,
we'll
reject
the
proof
if
it's,
if
it's
invalid.
C
So
so
so
that's
not
a
requirement
for
safety.
However,
when
it
comes
to,
let's
say,
let's
say,
permissionlessness
and
censorship
resistance,
it
is
quite
important
for
this
this
this
infrastructure
to
not
rely
on
any
any
I,
guess
Authority
or
whitelisted
relayer
or
additional
trusted
environment,
so
that
that
that
that
that
essentially
like
is
a
requirement
for
the
whole
workflow
to
go
to
so
so.
C
There's
there's
before
before
these
kind
of
ibcs,
which
are
I,
think
the
the
current
I
guess
like
at
the
at
The
Cutting
Edge.
Let's
put
it
this
way,
there
were
a
number
of
iterations
that
were
essentially
like
the
step
before,
if
you,
if,
if
you
want
one
good
example
in
the
in
the
Antelope
or
back
in
the
esio,
space,
was
bus
score.
So
bus
score
was
that
chain
that
launched
in
late
2018
and
they
had
a
actually
a
cryptographically
secure.
C
So
when
we
designed
our
IBC
one
of
the
I
guess
criteria,
that
was
a
requirement
was
to
not
have
this
requirement
of
a
third
party
acting
as
a
permission,
relayer,
and
also
we
wanted
to
make
sure
that
the
user
themselves
would
be
able
to
like
generate
their
own
proof
and
submit
the
proofs
to
the
other
chain,
so
so
that
that
was
essentially
to
ensure
that
that
permissionlessness
and
that
censorship
resistance
would
be
would
be
maintained.
So
we
we
got
pretty
far
in
that
direction.
C
You
know
like
putting
the
money
at
risk.
They
we
don't
want
them
to
be
able
to
selectively
deny
a
service
or
for
for
users
to
depend
on
them
as
they
as
they
perform
these
transactions.
So
we
we
have
to
start
somewhere.
So
we
started
with
the
diffuse
history
solution
that
we
use
to
generate
proofs
to
a
proof
server.
C
It
says
not
a
requirement
in
a
sense
that
we've
built
also
a
more
complicated
light
clients
that
will
fetch
these
proofs
by
themselves
and
are
are
basically
could
be,
could
be,
we've
done
it
in
the
browser.
It's
not
necessarily
a
big
deal.
It's
just
that
it's
it's
a
bit
less
convenient,
because
now
the
the
client
has
to
know
more
about
about
what
what
data
has
to
be
fetched
and
has
to
calculate
more
things.
So
we
decided
to
create
this
intermediate
step,
which
is
essentially
what
we
call
the
proof
server.
C
D
I
think
I
dreamed
before
the.
If
changes,
though,
like
as
you
mentioned,
it
is
possible
for
you
to
just
grab
the
block
headers
and
construct
the
the
proof
yourself
that
what
we
call
the
heavy
proof,
the
proof
that's
based
on
the
finality
algorithm
we've
also
talked
about
you
know.
Instead
of
relying
on
this
extra
software,
maybe
as
part
of
the
standard
apis
provided
by
nodius,
you
know
we
could
have
the
the
Merkel
Witnesses
the
hashes
so
that
you
can
construct
through
standard
apis.
D
The
What's
called
the
light
proof
that
actually
goes
back
to
the
the
question.
The
the
discussion
here
we
had
earlier
earlier
about,
like
there's
no
permission,
you
don't
need
to
coordinate
with
some
Central
party,
no
matter
what
everyone
else
is
doing.
So
the
contract
is
designed.
The
bridge
contract
is
designed
so
that,
if
other
people
are
adding
in
their
own
heavy
proof,
so
things
are
advancing.
D
D
E
C
C
It
needs
to
be
extended
by
essentially
two-thirds
plus
one
block,
like
like
block
producers
times
two
rounds
so
like
you
have
to
to
essentially
go
through
two
rounds
of
two-thirds
plus
one
block
producers
adding
a
block
on
top
of
a
like
reference
block
for
that
reference
block
to
become
final,
irreversible.
So
now
the
heavy
proof
essentially
replicates
that.
C
So
we
verify
for
a
specific
block
that
we've
that
that
we've
achieved
essentially
consensus
by
verifying
all
of
these
signatures
that
are
required
to
reach
finality
for
that
particular
block.
Now,
once
that's
done,
we
we
essentially
save
the
Merkle
root
of
that
block,
that
we
just
verified
in
the
contracts
RAM
and
in
such
a
way.
Now
that
any
block
prior
to
that,
one
can
now
be
also
proven
through
what
we
call
the
light
proof
scheme.
C
So
that's
one
of
the
properties
of
a
of
a
of
a
Merkle
tree
is
essentially
as
you
as
the
Merkel
tree
grows
as
you're.
Adding
more
leaves
to
that
tree
it
essentially
in
in
the
case
of
antelope.
There
is
a
kind
of
data
structure
that
contains
a
representation
of
like
a
minified
representation.
If
you
want
of
that
tree
that
evolves
every
time
you
add
one
leaf
from
which
you
can
reconstruct
essentially
the
a
a
like
cryptographic
chain
linking
any
block
to
the
current
root.
C
So
if
I
have,
if
I
have
like
a
block
1000,
for
example,
that
I've
been
able
to
prove
now
I
I
want
to
prove
an
older
block.
Let's
say:
block
500
I
can
take
that
Merkle
tree
structure
and
construct
a
proof
that
will
connect
my
block
500,
all
the
way
back
to
the
root
of
the
block
1000,
and
that
cryptographic
proof
now
can
be
used
to
demonstrate
that
the
specific
block
has
been
included
in
the
history
of
the
chain.
So
by
doing
so
it's
a
it's
a
much
much
lighter
version
of
the
heavier
proof.
C
Hence
the
name
like
proof
that
can
that
can
be
verified
faster,
that
takes
far
less
space
and
that
allows
to
prove
any
action
or
any
any
transaction
that
occurred
since
the
Genesis
of
the
blockchain.
Now,
there's
a
downside
to
that
which
is
essentially
in
order
to
generate
that
proof,
you
need
to
also
have
access
to
more
historical
data
and
specific.
D
You
don't
have
to
you
can
if
you
want
to,
it
might
make
sense
to
do
so.
You
don't
have
to
use
a
heavy
proof
for
every
single
action.
All
you
really
need
is
a
heavy
proof
for
every
block
from
The
Source
chain
off
the
destination
chain.
Just
one
like
you
could
have
a
service
do
this,
but
again
it's
not
required
to
have
a
centralized
service
to
do
it.
Anyone
could
do
it,
but
for
efficiency,
if
someone's
doing
it
for
you,
you
could
just
leverage
that
and
just
use
light
proofs
to
actually
efficiently
prove
your
actions.
B
C
So
because
of
that,
of
course,
there's
there's
there's
a
significant
delay
before
a
a
an
IBC
transaction
can
be
considered
final
and
safe,
and-
and
this
is
one
of
the
definitely
very
interesting
benefits
of
instant
finalities,
now
we'll
be
able
to
reduce
that
time
to
yeah
like
a
few
seconds
like
low
single
digit
seconds,
which
which
drastically
improve
the
user
experience
and
can
also
extend
quite
quite
a
bit
the
range
of
applications
and
can
now
take
advantage
of
that.
So
that's
that's.
E
A
C
Tiny
bit
more
latency,
of
course,
because,
like
that
that
that
information,
that
proof
has
to
be
relayed
to
another
another
chain
has
to
be
verified
by
that
smart
contract.
But
it's
it's!
It's
not
not
very
much
in
the
the
grand
scheme
of
things
like
if
we
are
right
now,
for
example
like
if
it
takes
just
under
three
minutes
to
to
reach
finality
on
the
on
a
specific
block
as
it
stands,
we
can
have
you
know,
like
the
the
proof
verified
by
the
smart
contract.
C
You
know
like
in
the
next
0.5
seconds,
and
chances
are
like
0.5
seconds
after
that's
done,
so
the
same
kind
of
would
apply
there.
So,
like
you
would
have.
You
would
have,
of
course,
a
bit
of
latency
that
that
would
represent
the
time
that
it
takes
to
build
the
proof
to
package
it
submit
it
to
the
smart
contract
and
for
the
smart
contract
to
verify
it,
but
it
and
and
like,
for
all
intents
and
purposes,
it's
pretty
much
the
same
speed.
Basically.
D
Yeah,
so
it's
just
to
add
to
that
that's
a
little
bit
of
extra
time
added
on
like
so.
You
first
have
to
wait
until
it's
fine
before
you
can
prove
the
other
chain
and
then
there's
a
little
bit
of
extra
time,
as
Dale
mentioned,
to
generate
the
proofs
validated
and
all
that.
But
that's
for
one
hop
and
I
just
just
to
stress
the
importance
of
like
how
big
of
a
difference
is.
D
The
finality
can
make
the
IPC
it
it's
not
just
what
neces
I
mean
some
applications
as
simple
as
just
one
hop
just
sending
a
message
from
here
to
there,
but
when
you
get
more
complicated,
there
might
be
a
lot
of
back
and
forth
messages
needed
to
carry
out
some
overall
cross
chain
operation
and
imagine
with
the
current
algorithm
for
three
minutes.
Each
message
taking
three
minutes
back
and
forth
I
mean
I
would
use
an
analogy
of
like
going
from
snail
mail
to
email,
just
the
back
and
forth
right.
D
That
makes
a
huge
difference
if
you
drop
like
the
latency
from
each
one
for
three
minutes,
just
like
a
couple
seconds,
there's
more
I
think
that
can
be
done
there,
and
this
is
From
perspective
without,
like
the
future
of
IBC.
As
I
said,
like
I
said,
this
is
the
basic
mechanism
of
message
passing,
there's
potentially
other
things.
One
could
do
with
other
protocol
changes
that
could
Leverage.
D
You
know,
could
kind
of
compress
multiple
back
and
forths
needed
to
enable
a
cross
chain,
charted
application
and
sort
of
speed
up
the
time
it
takes
to
do
a
single
operation,
ultimately
they're
all
based
on
this
mechanism
of
sending
messages
back
and
forth,
but
and
so
they
benefit
from
instant
finality.
But
there's
a
lot
more
to
it.
I
think
that
we
could
explore
with
IBC
in
the
future,
but
as
it
is
just
right
now
with
message
about
saying.
C
Yeah,
it's
a
very
good
point
like
when
you,
when
you
think,
let's
say
how
communication
used
to
work
when
people
would
send
letters
to
to
the
mail
like
to
a
courier.
You
know
like
I'd,
write
the
letter.
You'd
get
it
like.
Maybe
two
three
days
later,
you'd
respond,
I'd,
get
it
two
three
days
later
and
and
so
on
and
so
forth.
C
So
of
course,
if
you're
able
to
shrink
that
delay
that
communication
delay
to
a
few
seconds,
then
you
can
add
that
back
and
forth
happen
in
in
pretty
much
in
real
time
and
and
a
whole
new
range
of
applications
now
become
possible
that
were
not
possible
before
that.
So
especially
when
we
start
talking
about,
let's
say
like
like
sharding
or
what
what
I
like
to
call
side
chains-
and
you
know
like
very,
very
rapid
synchronization
of
State
across
different
different
chains.
A
Awesome
and
yeah
that's
some
of
the
stuff
that
we
could
get
into
in
a
in
a
further
conversation
which
I
think
we
should
have
which
may
touch
on
some
of
the
implications
of
the
adoption
of
the
Hot
Stuff
consensus
and
yeah.
Other
improvements
from
instant
finality,
including
sharding
and
side
sidechain
type,
stuff
and
yeah
or
I,
could
probably
summarize
or
tease
some
of
those
better
than
I.
D
A
D
C
D
The
basic
fundamental
mechanism,
but
how
could
one
build
upon
it
to
address
the
problem
of
scale,
really
scaling
applications?
There's
all
these
governance
aspects
to
think
about
like
what
do
you
do
with
accounts?
How
do
you
manage
accounts?
How
do
you
manage
resources?
There's
a
lot
of
there
are
a
lot
of
things
to
figure
out
like
again
we're
starting
with
this
primitive
mechanism
of
message
passing
and
then
with
with
just
the
finality
improving
audio
making
it
faster,
but
there's
a
lot
more
to
do
beyond
that.
So
I
think
there's
a
lot
of
discussions
too.
D
A
lot
of
interesting
discussions
to
have
there
a
lot
of
things
we
have
to
first
figure
out
frankly
regarding
IBC
as
it
goes
in
the
future
regarding
instant
finality
there's
a
lot
we've
already
discussed,
some
of
which
is
expected
of
that
I
think
would
be
interesting
to
talk
about.
So
one
of
the
things
we
didn't
mention
here
that
Kim
and
I
have
been
talking
about.
A
lot
is
how,
with
with
this
the
finality,
we've
really
been
thinking
about
how
some
of
these
roles
are
distinct.
D
So
we've
often
thought
about
block
producers,
but
really
at
the
level
of
the
consensus,
algorithm
we're
starting
to
think
about.
Well,
there's
really
a
block
proposer
and
there's
a
block
finalizer
and
there's
a
consensus
leader
and
those
are
technically
all
different
roles
for
for
it's,
the
finality.
What
we're
doing
initially
is
just
collapsing
along
to
one
rule,
block
producers,
nothing
changes
there,
but
it's
really
interesting
to
think
about
what
could
happen
if
we
were
to
actually
decouple
some
of
these
roles.
But
what
opportunities
do
those
enable
and
not
only
that
I'd
reference?
D
You
know
the
proofs,
the
cryptographic
proofs,
including
the
one
of
I,
guess
what
they
call
a
finality
violation
where
you
know
the
victim
was
tricked
under
a
double
spend
attack.
How
did
they
prove
that
they
were
tricked,
so
they
could
analyze
the
Bad
actors
I,
so
I
referenced
that
a
little
bit
in
terms
of
the
actual
algorithm
supporting
that.
D
So
you
know:
there's
a
nice
property
to
have
in
the
consensus
algorithm,
but
there's
a
whole
other
layer
of
a
consensus
mechanism
that
builds
on
top
of
the
algorithm,
which
adds
all
the
economics
to
it
right,
which
I
said
was
very
important.
It's
one
thing
to
have
these,
like
CS
properties
of
you,
know
busy
default
tolerance
and
everything,
but
it's
a
whole
thing
to
trust
that
your
mechanism
is
something
you
can
actually
rely
on
and
that's
where
the
economics
comes
in,
and
so
that's
where
we
could
maybe
talk
about
things
like
what?
D
A
C
Yeah
I
guess
it's
there's,
there's
quite
a
few
factors
that
will
play
a
role
in
in
that
number
and
that
will
include
that
will
include,
for
example,
The,
Logical
and
geographic
distribution
of
the
nodes
that
are
essentially
composing
the
network.
How
many
layers
do
you
have
between
like
of
essentially
like
net,
like
notes,
hops
between,
say
blood
producers
and
how
well
they're
meshed
together
what
what
are
the
overall
conditions
on
the
network?
C
It
was
more
to
the
tune
of
two
2.5
and
I
think
we
can
potentially
do
even
better,
so
so
so
we
could
have.
We
could
have
possibly
a
a
little
bit
lower
than
that.
It
depends
on
a
lot
of
things,
so
I
mean,
of
course,
like
performance
will
vary
across
different
networks
across
different
network
like
topographies
and
meshing
characteristics.
Also
with
the
load
like
with
the
how
big
are
the
blocks
and
how
much,
how
much
of
the
the
I
guess
like
the
bandwidth
is
being
consumed,
but
it
that's.
C
B
B
Take
us
on
home,
yeah,
I'm
gonna,
listen
to
this
like
three
or
four
times
to
be
able
to
like
comprehend
it,
but
it's
good
to
be
surrounded
by
really
technical
people
who
are
first
hand
working
on
these
projects
and
to
see
the
space
evolve
in
front
of
our
eyes.
So,
thank
you
all
of
you
for
doing
that.
We'll
keep
it
updated.
Is
there
any
way
to
follow
any
of
your
work?
Twitter
any
other
place
blogs
newsletters.
Do
any
of
you
want
to
share
any
of
that.
C
You
can
can
probably
start
thinking
about
how
we're
gonna
start
disseminating
that
that
new
information
it
definitely
has
to
has
to
get
out
at
some
point.
People
have
to
to
be
aware
of
what
what's
cooking
but
yeah
I.
Think
I.
Think
it's
a
good.
It's
a
good
call
to
action
on
our
end.
To
start
start
thinking
about
that
as
well.
Yeah.
B
C
A
C
I
think
you're
right
there
yeah,
we
just
started
yep
yeah,
so
so
yeah
so
like
we'll
we'll
we're
in
the
process
of
kind
of
organizing
documentation
together,
we'll
we'll
work
with
you
guys
to
craft
the
the
message
and
I
think
that
those
guys
also
wanted
to
to
help
out.
So
it
will
be,
it
will
be
a
process,
but
but
it
will
eventually
get
done.