►
Description
Leap 5.0, the second hard fork release for the EOS after Leap 3.1, aims to introduce Instant Finality (IF) and boost performance. This is the first instance where the underlying consensus algorithm will be updated, although not yet activated, on EOS. The upgrade includes a feature developed by Gnome, UX Network Lead Engineer and Areg Hayrapetian, Director of Engineering - ENF. The HotStuff consensus mechanism, initially developed by VMware, will be incorporated for faster block finality. A new API has been introduced, allowing light clients to understand transaction states without accessing full block details, thereby facilitating application development.
00:00:00 Intro
00:01:11 EOSVM OC Integration in Blockchain
00:02:45 Instant Finality in the Leap Hard Fork
00:05:29 Introducing the Hot Stuff Consensus Algorithm in Leap
00:07:20 Decoupling of Roles
00:14:57 Implications of Leap's Innovations for Inter Blockchain Communication (IBC)
00:18:19 The Widespread Adoption of the Hot Stuff Consensus Algorithm
00:23:29 IBC potential with non-Antelope chains
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
Gonna
give
an
update
on
what's
coming
up
with
leap
5.0.
A
lot
of
my
time
now
is
spent
on
eocvm,
but
beyond
that
focused
on
still
supporting
leap
and
particularly
on
Insta
finality
that
I've
been
working
closely
with
Gilman,
so
lead
5.0,
Antelope
5.0.
This
is
a
the
second
hard
Fork
release
that
we're
doing
as
as
far
as
as
far
as
the
as
far
as
the
enf
is
done
for
ES.
A
So
the
first
one
was
leap
3.1
that
was
the
one
that
kind
of
split
us
off
from
the
old
code
base
and
signals
so
that
to
everyone
that
es
is
now
separate,
separated
from
the
past
and
the
and
the
community
is
now
driving
development
of
the
code.
So
if
you
remember
that
was
last
year,
September
late
September,
that
the
feature
was
activated
the
protocol
features,
and
so
now,
a
year
later,
more
than
a
year
later,
we're
planning
another
hard
Fork
release
and
that's
what
will
be
included
in
leap
5.0.
A
The
main
feature
in
leap
5.0
is
instant
finality,
which
is
it's.
What
we're
gonna,
Kim
and
I
are
going
to
talk
about
right
now,
a
little
bit
go
into
that
a
little
bit.
There
are
other
features
as
well,
but
that's
the
primary
the
most
exciting
one
really
is
is
the
finality.
I
will
mention
one
other
thing
that
is
close
to
me
as
far
as
a
secondary
feature,
though
in
5.0
I
won't
mention
them
all.
A
A
For
why
we've
prioritized
this
for
5.0
is
that
we
could
leverage
ESPN
OC
to
speed
up
es
evm
the
es
evm
contract
and
get
even
greater
performance
from
that.
So
I'm
really
excited
about
that.
There
are
a
few
other,
smaller
features
as
well.
That
are
already
done
kind
of
included
as
part
of
that.
But
the
most
exciting
feature
is
this:
is
the
finality
feature,
which
is
a
consensus?
A
B
Sure,
thanks
thanks
for
that,
I
guess,
introduction
to
that
new
feature.
I've
heard
a
little
bit
Through
the
Grapevine
and
I'm
also
very
excited
about
the
selective.
Yes
VM,
oh
see,
that's
that
don't
think
that's
going
to
be
really
cool
for
or
a
number
of
a
number
of
purposes
so
really
really
excited
to
see
that
coming
come
to
life
as
well.
B
Coming
back
to
instant
Fidelity.
This
is
this
is
something
we've
been
working
on
for
quite
a
while
now
and
we're
really
in
the
I
guess
like
in
the
thick
of
it.
Now
it's
we.
We
discussed
it
a
little
bit
on
I
think
a
couple
weeks
ago,
but
there's
there's
just
so
much
to
so
much
talk
about
about
that
feature.
There's
we
we
call
it
instant
finality.
This
is
the
name
that
typically
people
have
been
using
to
refer
to
this
upgrade,
but
in
reality,
what
we're?
B
What
we're
really
doing
is
we're
introducing
the
Hot
Stuff
consensus
mechanism
to
to
leap
and
the
hudstock
consensus
mechanism
is
an
algorithm
that
was
developed
Back
in
the
Day
in
2018
by
VMware.
I.
Think
I've
mentioned
that
on
the
previous
fireside
chat,
just
as
as
a
refresher,
and
it
was
selected
by
the
Libra
cryptocurrency
project
that
was
sponsored
by
Facebook
and
that
didn't
didn't
see
the
ended
up,
seeing
the
light
update.
B
But
that
was
that
was
at
the
at
the
their
conclusion,
as
they
spent
all
that
time
to
do
research
on
various
consensus
mechanisms
and
they
selected
that
one
because
I
had
some
some
very,
very
interesting
properties,
and
it
was
really
one
of
the
I
guess
state
of
the
art
consensus
models
out
there,
and
it
still
is
today.
That's
still
probably
one
of
the
best,
if
not
the
best
that
currently
exists
and
when
we
started
working
on
the
instant
finality
proposal.
B
Eric
and
I
were
discussing
various
options
and
Eric
actually
was
a
very
big
proponent
of
hot
stuff
and
convinced
me
essentially
to
to
basically
like
build
instant
Fidelity
on
hot
stuff.
At
the
time,
I
was
considering
doing
something
that
looked
a
little
bit
more,
like
Casper
the
ethereum
2.0
consensus
model.
But
after
after
a
few
discussions
with
Eric,
it
became
very
clear
that
that
stuff
was
the
the
main
Contender
and
probably
most
definitely
a
better
choice.
So
thank
you.
B
Eric
for
convincing
me
I
was
I
was
a
little
bit
skeptical
at
first,
but
didn't
take
too
long
and
now
I'm
I'm
very
glad
we're
doing
it
that
way,
and
there
there's
Beyond
instant
finality,
which
is
definitely
a
great
feature
to
have
to
have
blood
finality
that
occurs
near
instantly.
The
Hot
Stuff
consensus
algorithm
has
this
property
called
optimistic
responsiveness
which
allows
you
to
as
an
Network
to
reach
finality
pretty
much
as
fast
as
the
network
will
allow
it.
So
it's
kind
of
you
have
to
do
a
few
back
and
forth
between
your
finalizer
nodes.
B
The
the
nodes
I
will
decide
on
the
finality
status
of
of
a
block
or
proposal,
but
it
essentially
allows
you
to
reach
that
analogy.
State
as
fast
as
network
will
allow.
So
this
is
quite.
This
is
quite
interesting
because,
most
of
the
other
consensus
models
out
there,
they
have
a
it
basically
takes
a
certain
period
of
time
that
is
usually
like
fixed
or
that
that,
like
a
specific
interval
that
is
required
to
wait
until
all
the
nodes
agree
on
the
finality
status
of
the
block.
B
But
here
we're
essentially
able
to
do
it
as
fast
as
we
as
we
can
as
a
network
will
allow
it.
So
that's
why
we
we
call
it
instant
Fidelity,
it's
really
really
yeah
as
fast
as
faster
the
network
will
allow
and,
of
course,
in
some
scenarios
it
will
also
be
probably
even
faster,
like
if
you're
running
this
on
a
private
chain
or
if
you're
running
this
on
the
test
net.
That
has
a
very
tight
meshing
between
your
nodes.
B
You
can
you
can
theoretically
reach
finality
even
before
the
next
block
is
being
produced
place
in
theory,
but
this
is
quite.
This
is
quite
fascinating
in
terms
of
I
guess
like
a
piece
of
technology
like
when
you're
able
to
reach
a
finality.
That
fast.
That's!
That's!
That's!
That's
really
nice,
but
this
is
just
one
of
the
benefits
of
hot
stuff.
We've
discussed
a
little
bit
I
think
two
weeks
ago,
we
discussed
also
what
it
allowed
us
to
do
in
terms
of.
A
I
think
yum
was
just
about
to
start
talking
about
was
the
decoupling
of
different
roles
that
are
currently
handled
by
a
single
entity,
the
block
producer.
So
in
hot
stuff
there
are
distinct
responsibilities
we
could
out.
We
can
describe
so
one
is
a
block
proposer,
so
the
block
proposer
would
be
the
entity.aggregates
transactions
that
are
coming
into
it
into
into
a
block
into
the
in
a
certain
order
and
that's
a
block
that
can
be
added
to
the
block
blockchain,
and
that
doesn't
mean
it's
final.
It's
just
a
proposal.
A
It
comes
aggregated
signatures
that
act
as
a
proof
to
any
user
that,
according
to
the
consensus
algorithm,
this
block
is
final
and
when
the
block
is
final,
it
means
that
all
prior
blocks
in
the
chain
up
to
that
point
and
all
the
transactions
within
them
are
also
final.
They're,
irreversible
is
another,
a
synonym
for
that.
A
That
is
more
common
in
the
Antelope
side
of
things,
and
then
a
third
responsibility
is
supposedly
in
hot
stuff
is
consensus
leader
and
the
the
consensus
leader
is
coordinating
with
the
block
finalizers
to
generate
that
final
proof,
which
we
call
a
quorum
certificate,
which
is
a
basically
you
think
of
it
as
a
signature
that
convinces
the
rest
of
the
world
that
this
block
is
final.
But
to
get
to
that
point
requires
multiple
iterations,
multiple
rounds
of
back
and
forth
communication
between
the
assets
leader
and
the
block
finalizer,
particularly
in
hot
stuff.
A
That
requires
requires
three
phases
back
and
forth
communication.
So
the
consensus
leader
is
the
entity
that
Aggregates
all
the
block
finalizers
signatures,
we're
leveraging
Els
signatures,
which
has
this
wonderful
property
that
you
can
take
as
many
signatures
as
you
want
and
aggregate
them
together
into
one
signature
that
effectively
captures
the
sign
the
signature
of
all
the
participants
in
in
one
cryptographic,
signature.
A
So
that's
those
are
the
rules
and
right
now
you
could,
with
the
current
successes
algorithm,
you
can
think
of
the
block
producer
in
EOS
as
playing
as
as
acting
in
all
of
those
three
roles.
It
certainly
is
the
block
proposer.
The
signature
that
is
added
onto
that
block
also
acts
as
a
block.
Finalization
signature
according
to
the
existing
consists
algorithm.
A
The
consensus
leader
isn't
really
necessary
in
the
current
successes
algorithm
as
a
role,
it's
it's
more
just
the
block,
so
the
this
is
actually
the
reason
why
aha
stuff
is
so
much
faster
than
our
current
algorithm.
The
current
algorithm,
the
process
of
all
the
block
finalizers
signing
for
whichever
phase
spread
across
multiple
blocks,
so
you're
limited
to
one
block
or
whatever,
every
half.
A
Second,
as
an
opportunity
for
one
block,
finalizer
block
producer
in
this
case,
providing
their
signature
and
then
that
Aggregates
over
time
and
there's
two
phases
of
that
before
you
have
essentially
accumulated
enough
signatures
for
a
validating
node
to
now
know
that
this
block-
you
know
at
this
point
300
so
blocks
back
in
the
history
of
the
chain-
is
now
considered
final,
which
is
why
you
see
this.
This
lag
of
300
something
blocks
and,
what's
worse,
is
that
that
scales
with
the
number
of
block,
finalizers
or
block
producers,
so
on
EOS
with
21
block
producers.
A
That
means,
if
you
do,
the
math
it
works
out
in
about
a
three
minute
gap
between
the
head
block
and
the
last
year,
reversible
block,
but
with
hot
stuff.
All
this
stuff
is
happening
as
fast
as
Network
conditions
allow.
So
all
of
the
block
finalizers
are
signing
in
parallel
at
the
same
time
and
they're,
sending
the
messages
to
the
consensus
leader
and
there's
a
few
more
rounds
of
that
necessary,
but
they're
happening
as
soon
as
the
first.
The
prior
round
is
done.
A
You
don't
have
to
wait
until
a
block
is
produced
with
the
the
event
driven
hot
stuff
that
we're
we're.
Basing
this
you
can
send
this
algorithm
on,
and
so
that
does
require
this
other
role
of
a
consensus
leader
to
manage
that.
But
what
it,
what
it
gives
us
is
basically
a
very
fast
time
to
finality
a
very
low
time
to
finality,
so
that
that's
a
difference,
a
key
difference
between
the
old
and
new
algorithm,
which
explains
why
this
one
is
much
faster.
But
anyway,
going
back
to
the
roles.
A
So
the
block
producer
effectively
consensus
leader
isn't
necessary,
but
the
block,
proposer
and
block
finalizer
roles
were
combined
in
a
single
role
that
we
call
the
block
producer.
So
with
hot
stuff,
we
have
the
opportunity
to
decouple
those.
It
doesn't
mean
you
have
to
decouple
those
and
just
to
be
clear
with
the
5.0
upgrade.
We
are
continuing
to
bundle
all
of
those
roles
together
in
in
just
the
block
producers
that
are
selected
in
the
same
way
according
to
dpos,
as
they
have
always
been.
So
this
is
a
point.
A
That's
maybe
a
little
confusing
to
people,
but
the
way
I
like
to
think
of
it
is
the
consensus
algorithm,
which
is
what
we're
really
changing
in
5.0.
Is
this,
you
know,
is
the
this
algorithm
that
determines
finality
given
a
set
of
consensus
participants.
It
does
not
tell
you
how
you
should
determine
that
set
of
consensus
participants.
It
doesn't
tell
you
how
you
should
divide
up
the
roles
across
different
entities.
A
It's
just
the
you
know
the
core,
your
science
parts
of
things,
because
of
this
mechanism,
how
I
Define
it
is
this
broader
concept
that
builds
on
top
of
the
consensus
algorithm
and
adds
all
of
the
other
stuff
like.
How
do
you
decide
on
a
block
proposer,
a
block
finalizer?
How
do
you
decide
which
wants
to
select
how?
What
are
there
is
there
staking
involved
and
if
they're
voting
involved,
is
there
penalties?
You
know
the
economics
of
all
that
get
brought
in,
so
we
haven't
really
given
a
name.
A
We
are
changing
the
consensus
algorithm
part
of
that
to
a
new
one,
that's
based
on
hot
stuff,
but
we're
keeping
the
existing
consensus
mechanism
of
dpos,
so
that
continues
just
like
it
has
we
still
select
in
ones
which
continue
to
still
select
top
21
block
producers.
Those
block
producers
would
continue
to
now
act
as
a
block
proposer
and
a
block
finalizer
and
also
a
consensus
leader
in
the
same
way
that
we
we
route
we
kind
of
round
robin
through
block
proposers.
B
Roles
and
there's
another
thing,
though
I
wanted
to
to
bring
up
and
which
is
quite
interesting,
of
course,
as
we
as
we
started,
working
on
instant
Fidelity.
One
of
the
reason
personally
I
got
interested
in
the
topic
was
because,
of
course,
I
was
working
on
IBC
before
that,
inter
blockchain
communication,
and
this
is
now
giving
us
quite
a
few
additional
opportunities
for
IBC
as
well,
the
main
one
being,
of
course,
the
ability
to
shrink
to
reduce
the
time
to
Melody
and
thus
the
time
for
IBC
operations
from
about
three
minutes
to
a
few
seconds.
B
That
would
want
to
know
what
the
state
of
a
transaction,
for
example,
they're
interested
in,
might
be,
but
without
having
to
necessarily
care
about
all
the
other
blocks,
all
the
other
content
about
the
other
transactions
and
so
on.
So
you
can,
you
can
think
of
a
number
of
new
I
guess
like
ways
to
build
applications
that
would
not
necessarily
require
you
to
run
a
full
node.
You
can.
You
can
stay
in
sync
with
the
network
and
verify
that
the
certain
transactions
were
included
and
that
you
can
base
your
activity
on.
B
You
can
essentially
take
decisions
based
on
these
transactions
without
having
to
run
necessarily
the
full
blown
leap,
software
and
that's
kind
of
how
we're
doing
it
with
instant
with
IBC
we're
essentially
having
the
two
two
different
blockchains
act
as
light
clients
of
each
other,
but
now,
with
this
with
this
system,
we're
able
to
do
that
in
a
way.
That's
a
lot
more
I
guess
like
a
lot
more
convenient
from
the
application
standpoint.
So
this
is
something
I'm
really
excited
about
as
well.
B
I
can
see,
I
can
see
tons
of
applications
from
you
know,
a
simpler
mechanism
for
exchanges
to,
for
example,
list
yes,
tokens
or
other
tokens
built
on
yes
or
other
Antelope
chains.
I
can
see
also
this
being
very
useful
for
any
dab
developer,
really
that
the
intention
of
building
something
that
will
require
on-chain
verification
without
necessarily
wanting
to
run
full
nodes
and
things
of
the
sort.
B
So
this
is
quite
this
is
quite
an
important
Milestone,
I
think
for
for
leap
as
well
to
have
the
ability
and
the
convenience
to
do
things
like
this
without
necessarily
running
the
full
full
node.
So
so
I
don't
know
I,
don't
know
like
I,
don't
know
yet
what
we
will
see,
that's
going
to
be
built
on
top
of
that,
but
I
can
definitely
see
a
lot
of
opportunities
from
a
feature
like
this.
Is
there
anything
else
that
that
we
wanted
to
discuss
I
reg,
or
should
we
maybe
answer
a
few
questions?
A
Some
questions,
yeah
I,
would
definitely
want
to
hear
what
game's
opinion
is
on
this
question,
but
I'll
give
it
a
shot.
So
this
question
is
why
why
don't
you
think
many
chains
have
adopted
on
stuff
is
so
good?
What
are
the
downsides?
So
I
don't
have
like
a
great
answer
to
this,
but
I'll
give
you
my
my
opinion
of
my
speculation.
So
one
of
the
things
I
think
is
relevant.
A
Here
is
just
the
chronology
of
all
this,
like
people
adopt
excessive
algorithms
that
seem
pretty
good
at
the
time
and
then
there's
further
development
that
happens
and
then
there's
sort
of
inertia
that
limits
people
from
upgrading,
something
that
seems
to
be
working
well
enough.
Newer
chains
may
be
have
this
opportunity
to
choose
the
latest
state
of
the
art
and
adopt
that
there
are.
There
are
chains
out
there
that
have
faster
finality.
You
know
low
time
to
finality,
even
if
they're,
not
using
Hot
Stuff,
there's
different
various
other
approaches
that
may
be
okay.
A
One
thing
to
keep
in
mind
is
there
have
been
further
attempts
of
improvements
on
top
of
hot
stuff.
We
have
evaluated
some
of
those
but
decided
where
not
they're
they're
fairly
new
and
there's
a
risk
associated
with
that,
because
it's
really
important
to
have
a
system
that
is
sound.
That
is
that's
safe
and
you
know,
has
you
know
the
papers
prove
safety
and
liveness
as
you
make
tweaks
to
that,
there's
risks
that
you're
going
to
compromise
that
so
there's
other
advantages.
A
There's
other
you
know,
versions
that
built
on
top
of
our
stuff
changed
it
in
some
ways
claim
to
improve
it,
but
there's
a
question
of:
does
it
compromise
the
safety
or
liveness
properties
that
are
desirable
in
hot
stuff?
And
so
we
made
a
decision
that
some
of
these
advantages
weren't
worth
it
for
the
risk
of
going
for
something
kind
of
unproven.
A
We
want
to
stick
with
something
that
was
well
established,
seems
to
be
a
pretty
straightforward
in
terms
of
having
confidence
in
its
properties
and
its
proofs,
and
that
still
works
well
enough,
so
I
mean
we're
talking,
basically
we're
talking
about
very
fast
times
very
fast
process,
low
times
finality,
basically
driven
by
Network
conditions
really
than
anything
else.
One
other
thing
I'll
mention
is
like
some
networks.
A
Can
we
can
bring
like
Casper
like
there's
this
Legacy
of
using
proof
of
work
as
the
block
proposal
mechanism,
if
I
can
kind
of
bring
it
back
to
these
roles,
but
then
a
gadget
on
top
of
that
to
create
to
add
finality,
and
they
have
their
reasons
for
wanting
to
keep
that.
But
given
the
latency
kind
of
constraints
that
come
with
the
block
proposal
mechanism,
it
doesn't
necessarily
make
sense
to
take
advantage
of
things
like
optimistic
responsiveness
and
some
of
the
nice
properties
of
hot
stuff.
In
that
case
now,
why
would
they
stick
with
that?
A
Looking
at
the
history
of
EOS,
we
have
been
operating
with
with
this
system
where
we
have
a
restricted
set
of
entities
that
are
are
somewhat
trusted
selected
by
delegation
selected
by
the
stakeholders.
The
token
holders
and
they've
been
acting
as
the
block
proposers
and
block
finalizers,
and
so
there
doesn't.
A
The
other
thing,
though,
to
mention
that
is,
is
that
that's
current
case
with
EOS
but
hot
stuff
because
of
its
linear
signatures,
the
linear
size,
the
the
BLS
signatures
which
allow
for
linearly
aggregatable
signatures
means
that
we
can,
with
sir
bandwidth
issues
we
can
handle
a
much
larger
set
of
finalizers
than
we've
been
able
to
handle
before.
So
this
does
open
up
the
opportunity
to
increase
the
size
of
those
of
those
sets,
particularly
the
block
finalizer
set
is
something
that
could
be
considerably
increased
without
hurting
performance.
C
A
A
That's
very
similar
to
well
is
basically
identical
to
the
interface
in
the
EIP
and
ethereum
is
because,
if
your
M
2.0
supports
the
same
cryptographic-
and
so
we
intentionally
chose
that
particular
one,
because
it
enables
let
me
back
up
a
bit
so
IBC
requires,
on
both
ends
of
the
chains
that
they're
communicating
so
there's
a
source
chain
and
destination
change
on
both
chains.
You
need
to
have
code,
a
contract,
I,
guess
that
will
be
able
to
validate
the
proofs
of
the
consensus
algorithm
of
the
other
chain.
A
So
the
one
of
the
there's
others
upgrades
that
are
going
to
be
elite
5.0
are
exposing
the
host
functions
that
are
going
to
be
used
by
an
antelope
smart
contract,
also
being
developed
by
Yum's
team
to
validate
these
Quorum
certificates,
which
require
doing
a
BLS
signature.
Validations,
that's
going
to
be
needed
for
validating
messages
from
from
other
Antelope
chains
that
are
going
to
be
using
the
same
instant
finality
mechanism.
A
But
then
the
the
messages
that
are
being
sent
by
say
EOS
to
another
chain,
also
need
to
be
validated
by
the
Quorum
certificates
that
are
generated
by
instant
finality
on
EFS.
And
so
now,
when
we're
talking
about
IBC
with
another
blockchain
like
ethereum,
we
need
to
be
able
to
validate
those
Quorum
certificates
of
EOS
on
an
ethereum
smart
contract
and
that
and
yes
well
technically,
they
turn
complete.
You
could
run
anything
in
theory.
C
A
D
A
Believe
it
says
yeah
during
2.0,
so
that
was
regarding
ethereum
and
really
anything
else.
That's
actually
using
BLS
12
381
any
other
chain
like
that
could
could
we
would
have
the
necessary
foundations
to
quickly
validate
proofs
on
either
side
like
expose
that
could
enable
IBC
between
potentially
other
chains
beyond
that
BTC
is
a
completely
different
story.
I
know
that
yomez
talked
about
as
ideas
about
how
that
could
be
done
in
a
trustless
way.
A
Obviously
you
know
if
you're
willing,
to
give
up,
if
you're,
willing
to
trust
and
and
have
some
sort
of
third
party
do
things.
Then
a
lot
of
things
become
easier
with
gross
IBC,
but
the
standard
we're
aiming
for
is
trustless.
Standard
rearing
firm
is
to
not
add
any
more
trust
than
the
trust
people
already
have
for
the
consensus
algorithm
of
the
source
chain,
so
that
that
limits
what
you
could
do
in
terms
of
trustless,
let
me
see
between
yes
and
Bitcoin.
A
Unfortunately,
I
know
I
I
know
again
had
some
ideas
there,
but
I'm
not
really
aware
it's
actually
possible
or
not
in
the
trustless
manner,
so
that
was
kind
of
in
reference
to
sharonbot's
question
of
the
Karachi
index
of
BTC
and
USD,
so
that
you
know
the
tokens
live
on
these
different
blockchains
on
the
ethereum.
That's
fine!
If
we
have
a
ethereum,
EOS,
IBC
connection
and
trust
this
way,
but
the
and
of
course
we
already
have
usdt
on
on
ES,
but
yeah.
A
The
the
limits
of
getting
other
tokens
across
in
a
trustless
way
depends
on
the
IBC,
also
being
trustless,
which
is
question,
which
is
something
that's
you
have
to
take
on
a
case-by-case
basis
for
every
particular
blockchain
technology
and
the
consensus
Auto
we're
going
to
use
this.
Is
there?
Was
there
another
question,
I'm
missing
I
think!
Is
it
so
far?
Oh
here's
one
from
Perry
the
new
Hot
Stuff
Falls.
A
A
One
of
the
things
that's
interesting,
but
highly
speculative
at
this
point
is
if
we
were
to
decouple
block
production
from
block
finalization,
for
example,
then
could,
if
block
so
block
finalization
itself,
is
not
a
intensive
process,
but
you
don't
want
to
finalize
blocks
that
are
not
valid
because
part
of
finality
as
well,
is
this
attestation
by
the
finalizers
that
this
block
is
a
valid
blockchain.
It's
the
head
of
a
valid
blockchain,
so
block
validation
is
what's
more
resource
intensive.
A
If
there
is
a
potential
to
maybe
reduce
the
Hardware
intensity
intensity,
the
the
hardware
requirements
for
a
block
validator,
for
example,
if
we
could
find
ways
to
paralyze
it
more.
This
is
all
speculative
leap
implementation.
So
if
there
there's
a
way
to
paralyze
validation
more
so
you
can
use,
say,
lower
clock
cycle,
but
more
core,
a
machine
that
has
more
cores
but
lower
clock
cycles
and
still
keep
up
with
validation
and
and
maybe
those
machines
cost
less.
A
We
can
increase
the
numbers
and
claim
we're
more
decentralized
question
if
that's
actually
true
or
not,
but
it
does
come
at
a
linearly
increasing
cost
increase,
because
you
have
to
compensate
those
nodes
that
are
now
being
expending
resources
to
to
validate
things
in
an
available
manner.
So
there's
a
trade-off
there
of
how
much
decentralization
is
worth
it.
If
we
could
find
ways
to
this
decoupling
to
be
more
efficient
with
the
the
Hardware
costs,
then
the
trade-off
point
or
the
optimal
Point
could
be
shifted
further
towards
a
more
decentralized
number.
But
that's
highly
speculative.