►
Description
Anticipating the Leap 5.0 consensus upgrade, EOS core devs and Node operators examine the intricacies of the HotStuff Consensus, from dividing block producer and validator roles to ensuring system stability. As we await further documentation, discussions on key management and security are at the forefront.
00:00 Intro
00:25 Block Validation Vs Block Signing
02:42 Leap 5.0 Release Block Producer Roles
04:20 Future Expected Feature (Not in 5.0)
05:46 Who approves changes? Roles: Producers vs. Validators
07:30 What is the impact on how we operate?
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
B
A
So
it
and
the
the
new
consensus
mechanism,
there's
distinction
made
between
so
in
the
current
instances
mechanism.
There's
a
combination
of
of
things.
If
you
will
there
is
the
block
production,
there's
the
the
block,
validation
and
the
block
finalization
before
I,
given
for
a
given
block.
So
now
what
happens?
Is
you
you
produce
a
block?
You
sign
a
block
and
you're
implicitly
validating
the
block
that
you're
You're
Building
upon
right.
A
So
in
the
new
consensus
algorithm,
you
can
validate
blocks
that
you
have
not
built
upon,
so
you
can
just
validate
them
directly
as
they
as
they
come
into
your
node
and
then
communicate
that
out.
So
there's
a
distinction
here
between
validated
a
block.
That's
a
posted
I'm
I'm,
actually
producing
a
block,
and
we
can.
A
We
could
definitely
even
discuss
that
we're
not
talking
about
it
in
5.0,
immediate
relief,
but
we're
talking
about
potentially
separating
out
those
two
concepts
so
that
if
the
community
is
interested,
we
could
have
different
validators
than
block
producers
or
maybe
more
validators
than
block
producers.
You
know
they
don't
have
to
be.
They
don't
have
to
be
the
same
thing
anymore.
They
can
be
completely
separate,
and
so
so
you
have
the
separation,
there
are
of
concerns,
and
so
you
need
different
keys
for
for
the
those
two
roles.
A
A
5.0
right
from
from
where
we
are
right
now,
the
there's
no
plan
to
separate
those
two
concepts:
I
mean
we're
separating
them
in
implementation
until
we're
preparing
for
the
for
that
possibility.
But
that's
that's
really
a
decision
that
the
community
will
ultimately
need
to
make
and
then
we'll
have
to
actually
make
some
additional
code
changes
to
to
make
that
completely
possible
so
again
for
five
dollar
release.
It's
the
same
way
that
it
is
today,
if
you
will
so
a
VP
will
be
playing.
A
If
you
will
multiple
roads,
they
will
be
well
producing,
signing
and
validating
blocks
so
that
that
that
will
be
the
role
of
the
B
of
the
BP
and
currently,
as
as
we
have
it,
who
is
playing
the
leader
in
the
consensus
algorithm
that
which
could
also
be
separated
out.
Currently,
the
leader
is
following
the
block
producer
now
that
could
be
changed
in
the
future
as
well.
We
could
have
a
completely
separate
leader.
A
We
could
keep
a
leader
active
until
for
whatever
reason
they
go
down,
we
could
have
a
leader
either
Follow
by
one
or
be
one
ahead
in
the
schedule
where
it
could
fall
finalizer.
It
could
be
whatever
we
choose
like
there's,
there's
no
reason
to
couple
the
concept
of
a
leader,
a
validator
and
a
block
producer.
Those
three
concepts
can
be
completely
separated
in
the
new
consensus
algorithm
for
5.0.
Those
will
all
be
combined
in
in
the
block
producer.
E
A
A
The
other
kind
of
really
cool
thing
about
the
new
algorithm
is
like
we
could
now
again
none
of
this
in
5-0,
but
we're
building
it
and
getting
us
where
we
can
go
there,
and
you
know
in
the
future
is
that
if
a
block
producer
is
down
for
a
round
like
you
could
switch
to
a
different
block
producer
and
not
miss
a
complete
round.
So
that
could
be
a
part
of
the
the
new
consensus
when
we
have
it
in
place.
There's
no
reason
to
wait
a
full
six
seconds
of
no
block.
A
We
could
say
hey
this
block
producer
is
down,
let's
switch
to
and
I'll,
let's
switch
to
a
backup
or
any
series
about
backups
like
it
doesn't
even
have
to
be
a
single
backup.
It
could
be
many
like
people
could
then
like
buy,
for
that
ability
to
be
the
the
one
that
produces
the
block
and
there's
there's
there's
no
problem
with
with
that
scenario,.
A
That
other
one
yep
exactly
that,
so
that's
all
stuff,
not
in
5.0,
because
you
know
step
steps
here
we
got
to
get
the
consensus
algorithm
out
the
door.
You
know
which
we're
working
on
doing,
but
it
opens
up
all
kinds
of
really
cool
possibilities
in
the
future,
where
we
can
go
to
even
a
a
more
robust
system
than
we
have
today
and.
D
A
Yeah,
that's
a
really
good
question.
It
would
be
that
the
block
producers
still
for
any
sort
of
multi-stick
sort
of
thing
because
they're
the
ones
that's
actually
producing
the
blocks.
I
guess
somewhat
finalizers,
because
obviously
they're
the
ones
that
all
to
lay
are
going
to.
You
know
approve
of
the
blocks,
but
presumably
that
role
will
just
continue
to
be.
As
long
as
the
the
block
meets
consensus
parameters,
it's
going
to
be
validated,
you
know.
Hopefully
we
don't
get
into
a
situation
where
validators
are
like.
D
A
Mean
the
ultimately
a
value
or
validates
a
block
right,
and
so,
if
currently
today,
that's
simply
consumer
block
and
if
it
meets
consensus
then
then
it
considered
valid
right.
So
there
there's
not
any
logic
there
to
like
be
oh,
what
would
be
the
term
to
to
have
an
opinion
about
that
right,
so
yeah,
so
it
would.
It
would
be
the
the
BPS
in
his
job.
It
would
be
to
to
go
now.
D
Going
back
to
5.0,
this
won't
be
the
case.
The
only
thing
that
we
need
to
be
aware
of
is
okay.
Now
we
have
a
new
key
and
we
have
to
manage
that
key,
probably
differently
than
what
we're
doing
today
do
the
BPS
on
this
call
have
a
good
grasp
based
on
what
the
conversation
we
had
here,
what
is
the
impact
to
how
we
operate?
D
How
disruptive
is
this
change
to
the
way
that
we
operate,
and
you
know
how
much
care
are
we
going
to
have
to
to
Matthew's
point
that
you
know
this
is
something
we're
gonna
have
to
communicate
to
all
the
top
21
BPS,
whom
some
are
more
or
less
engaged
and
and
in
tune
with
the
intricacies
of
the
technology?
How
disruptive
will
this
be
for
those
and
and
us,
and
what
do
we
need
to
do
to
close
the
gap
there?
D
C
B
Well
I'll
say
this
I
mean
definitely
don't
have
a
good
grasp
on
it,
but
in
all
fairness,
because
there's
not
a
lot
of
documentation
out
and
really
all
the
details,
wouldn't
you
know
expect
to
have
a
good
grasp
to
really
be
able
to,
but
I
understand
and
I'm
excited
about
the
new
features
and
architecture.
But
yeah
I
mean
once
we
can
start
seeing
I
mean
what
is
it
like?
B
Is
it
really
just
simply,
I
need
to
manage
two
keys,
and
yes,
I
move
this
key
to
this
server,
and
this
key
now
and
I
comment
them
out.
You
know
I
mean
it
may
be
a
little
impactful,
but
it
may
not
be
detrimental,
or
is
it
not
even
possible
to
do
it
that
way,
and
now
yeah
we've
got
to
figure
out
whatever
so
the
more
technical
details,
maybe
an
RC
Anna
I,
here's
what
you're
expected
to
set?
B
B
F
I
think
the
answer
to
the
question
there
Dan
is
that
we
actually
just
need
some
more
detail
on
how
this
works,
and
then
we
can
tell
you
but
I
mean.
Does
the
key
do?
How
do
we
manage
the
keys?
You
know,
let's
just
get
solid
information
in
front
of
us
and
yeah
and
we
can
tell
you
how
disruptive
it's
going
to
be
right.
B
Us
or
could
it
use
some
type
of
you
know
mechanism
like
that
correct,
yeah,
I,
don't
know
if
it
requires
or
just
piggyback
on,
because
that
also
thoughtful
was
that
right
now
it's
all
the
BPS
and
yeah
I
mean
we
could
you
know
yeah
you're
signing
key
or
something
like
that.
If
you
start
getting
100
different
validators,
you
know
I
mean:
are
they
all
just
because
that's
one
thing
that
I
know
a
lot
of
rbps
that
are
you
know,
living
and
dying
in
this?
B
The
first
thing
they
do
with
their
block
signing
key
is
go
and
add
it
to
their
account.
That's
some
random
key.
You
know,
because
you
would
think
it
needs
to
be
Associated
to
an
account,
but
no,
no,
it's
just
registered
off
in
la
la
land
right,
you
know.
So
I
was
curious
if
it
fell
back
into
the
natural
structure
of
permission
or
could.
C
Anyway,
I
think
it's
an
important
question,
because
it
goes
to
the
security
of
that
and
how
things
get
matted
right,
because
the
person
who
controls
the
block
producer
is
not
necessarily
the
person
who
runs
the
nodes
and
so
the
permit.
The
permission
of
the
doing
this
node
transfer
needs
to
be
different
than
the
person
who
has
the
key
to
run
the
block
producer.
B
I
I
will
say:
yes,
we
have
dedicated
keys
with
only
the
unregged
permission
that
are
Minions
that
are
out
there
have
access
to
be
able
to
at
least
unrag,
maybe
not
even
re-ragged,
but
you
know
that,
but
I
mean
that's
not
it's
still
uses
the
permission
structure.
It's
just
what
action
you're
calling
but
yeah
I
mean
I'd,
assume,
there's
going
to
be
some
sort
of
action
to
register
a
new
validator
key
that
that
could
be
utilized
anyway.