►
From YouTube: Node Operator Roundtable - August 23rd, 2023
Description
The EOS Node Operator Roundtable meets every Wednesday at 14:00 UTC to share and discuss feedback to improve the Antelope protocol.
Timestamps
00:00:00 Introduction
00:01:09 Announcement: Deprecation of Deferred Transactions
00:05:06 Community Outreach: Sharing the Deferred Transaction Update via EOS Platforms
00:14:04 Leap Upgrade: Introduction of Instant Finality and Its Impact on Node Operation
00:14:51 Node Operation: Transitioning Between Production Nodes Using Different Finalizer Keys
00:18:47 Operational Best Practices: Key Management Recommendations for Reliable Transaction Response
00:44:21 Upgrade Challenges
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
Welcome
everybody,
it's
Wednesday,
August
23rd
and
we're
back
for
another
note
operator
round
table
today.
I
will
be
leading
the
call
to
talk
about
planning
for
the
the
big
consensus
upgrade
which
we're
targeting
for
in
early
December
December
6th
we've
got
a
schedule
here.
I'll
share.
Thank
you
Brian
for
pairing
this,
and
maybe
a
good
place
to
start
is
where
are
we
at
currently
in
the
schedule?
A
B
I
can
give
an
update
there,
so
I
don't
have
an
update
as
of
today
as
to
when
this
article
will
be
published,
but
the
as
of
yesterday
evening,
my
the
intention
was
to
publish
a
announcement
today
at
some
point.
So
I
still
expect
that
to
be
the
case,
although
I'm
going
to
be
working
on
updates
after
this
call.
B
So
anyway,
I
drafted
an
announcement
with
the
help
of
several
folks
internally
and
Brandon
Espinosa
and
arig
and
Kevin
and
and
others,
and
then
also
got
feedback
and
input
from
Daniel
and
Matthew
Darwin,
since
they
saw
it.
I
did
make
some
minor
changes,
because
we
had
a
a
conversation
about
the
actual
rollout
plan
as
part
of
5.0.
If
you
remember
this
deferred
transactions
disabling
is
targeted
for
before
five
doe
5.0,
but
then
there's
code
changes
targeted
for
5.0
itself.
B
B
I'll
start
posting
in
appropriate
telegram
channels,
just
calling
attention
to
that
it'll
be
posted
as
a
blog
post
on
esnetwork.com
and,
of
course,
if
there's
feedback
or
questions
we
can,
you
know
make
make
updates
or
clarify
in
those
channels.
What
I
would
ask
is
that
folks
help
spread
the
message
so.
C
B
C
B
Is
we
need
this
to
spread
the
message?
Not
because
it's
you
know
an
exciting
marketing
announcement,
but
because
we
need
you
know
the
community
to
rally
and
get
something
done
so
yeah.
So
that's
that's
the
status
of
that
I'll
and
then
you
notice
the
second
one
message
to
BPS
to
disable
on
Jungle
kailan
by
the
first
of
September
actually
runs
through
to
the
first
of
September,
because
I'm
gonna
sort
of
repeatedly
ping
there
so
and
yes,
this
is
what
Daniel
has
up
on
his
screen.
A
B
B
Apps
that
that
we
have
sort
of
done
some
bespoke
research
into
to
see
if
they're,
using
them,
that
that
do
have
some
touch
with
deferred
transactions,
so
we'll
be
doing
some
direct
door-to-door
directory
Outreach
for
them.
So
if
there
are
any
that
others
are
aware
of,
you
know
either
bring
it
to
their
attention,
actually
do
both
bring
it
to
their
attention
directly
and
also
bring
it
to
our
attention.
A
E
A
A
A
F
F
F
A
B
Basically,
both
of
them
have
a
no
earlier
than
and
no
later
than
all
right.
There
is
that
we
don't
wanna,
you
know
we
don't
want
folks
to
start
disabling
this
on
the
US
prior
to
application
developers
having
a
chance
to
you
know,
remove
their
dependency
on
it,
and
so
that's
why
the
the
date
there
for
application
developers
precedes
the
the
start
date
for
block
producers
on
ES,
but
then
there's
a
period
of
time
for
Block
producers
to
actually
make
the
change.
G
G
Now
we're
expecting
that
that
most,
if
not
all,
developers
that
are
all
applications
that
are
leveraging
dis,
deferred
transactions
in
one
way
or
another
already
have
a
backup
methodology
for
handling
because
deferred
transactions
fail
so
frequently.
So
we're
not
anticipating
there
to
be
a
a
major
implication
there.
On
the
DAP
side,.
A
A
Maybe
we
want
to
talk
about
a
little
bit,
the
instant
finality
stuff
or
just
more
broadly,
the
leap,
5.0
and
its
implications
to
node
operators.
I
understand
there
may
be
some,
maybe
some
changes
to
how
we
operate
as
node
operators
that
we
need
to
consider.
Maybe
we
need
to
change
some
of
our
processes
so
wondering
if
I
could,
if
we
could
spend
a
little
bit
of
time
talking
about.
A
D
E
H
Check
up,
okay,
all
right,
but
I
think
we're
we're
trying
to
get
the
best
path
forward.
And
then,
since
this
is
new
right,
we
haven't
we,
you
know
we
haven't
tested
100
of
all
scenarios
of
everything
that
happens
under
every
anything
that
happens
under
duress
right.
So
again,
we
want
to
build
in
margins
of
safety
what
we
can,
so
no,
it
wouldn't
really
jack
up
the
chain,
but
it
might
slow
things
down
or
tickle
take
a
while
to
get
back
to
consensus
again
if
old
messages
are
coming
back
in
so
I.
G
E
E
That's
such
a
key
piece
of
you
know,
Antelope
framework
to
have
multiple
keys
and
all
right,
whichever
one
primary
secondary
or
whatever
I
don't
know,
but
yeah
managing
multiple
keys
on
multiple
servers
is
we
actually
tend
to
go
the
other
way
because
to
change
Keys
you
got
to
wait
for
live.
You
gotta,
you
know,
get
it
to
a
working
node
that
you
may
think
is
working,
but
really
isn't
so.
We
tend
to
I
know
what
the
nodes
doing
way
more
than
I
can
control
with
the
chain
so
adhere
to
the
chain.
E
H
Yeah
well,
the
good
news
is
things
change,
so
in
this
case
you'll
you
won't
have
to
wait
for
the
the
last
year,
reversible
block
anymore,
but
you
could
just
switch
out
the
keys.
It
will
work
because
it's
a
much
more
robust
instance.
It
works
more
than
a
transaction
level
than
a
block
level
so
that
that's
the
good
news
I,
don't
think.
H
H
There
should
be
an
end
point
where
you
can
go
and
get
keys,
so
maybe
we
can
automate
some
secure
way
of
handing
them
off
and
generating
new
ones,
although
that
seems
like
not
one
that
we
would
like
and
probably
not
one
that
you
guys
would
like
either
but
I'm.
Just
throwing
these
ideas
out
there,
absolutely
and
and.
E
The
finale,
anytime,
being
quicker,
obviously
helps
a
lot
more.
You
can
react
and
try
to
get
into
the
chain.
The
biggest
other
issue
has
always
been
when
even
on
my
entire
network
would
think
it's
in
sync
or
it's
fine.
You
know
I
mean
it's
responding
and
accepts
it.
No
problem,
it's
just
the
rest
of
the
world
that
needs
that
information
never
gets
it,
and
it's
really
hard
to
know.
You
know
you're
constantly
doing
these
cross
validations
to
you
know,
Nations
or
sphere
to
say
how
are
they
doing?
Compare
me
to
them.
E
H
E
H
I
Isn't
there
something
in
send
transaction
to
that,
like
you
know,
part
of
that
old
retry,
doesn't
it
wait
to
see
it
in
in
an
actual
block,
that's
produced
potentially
by
someone
else
before
it
returns
it?
You
have
different
options
like
wait
for
certain
handoffs
or
wait
for
even
lib,
like,
wouldn't
that,
like
kind
of
be
a
result,
you
can
count
on.
E
D
I
Yes,
there's
multiple
failures:
there
is
like
a
heart
failure
when
it's
just
not
going
to
retry
any
more
resources
or
whatnot,
and
then
there
is
also
like
kind
of
like
where
you
specify
at
what
stage
you
want
to
get
the
result
back,
but
if
it
doesn't
make
it,
my
understanding
is:
yes,
you
do
get
an
error,
so
at
least
you
have
like
a
a
confirmation
like
if
you
do
get
the
correct
response,
you
know
that
it
made
it
to
whatever
state
you.
You
set
it
in
the
in
the
post.
E
Get
it
says
it
says
the
developer
I'm
trying
to
think
of
how
my
bash
script's
gonna,
do
it
by
supplier,
yeah,
curl
command,
or
something
but
or
clios
anyway.
So,
yes,
that
that
definitely
would
probably
help
with
that.
But
those
are
really.
The
two
main
issues
was
the
time
to
react,
live
and
then
just
being
able
to
know
whether
it
worked
and
respond
accordingly,
all
right,
try
Ross's
note
if
mine
didn't.
I
I
do
remember:
there
was
something
at
some
point
that
I
tested
and
it
was
working,
but
I
heard
there
was
complications
and
might
never
make
it
into
production,
which
was
this
ability
to
provide
multiple,
Keys,
multiple
signing
keys
for
a
producer,
and
it
will
auto
like
even
if
the
two
machines
received
it's
like
the
first
one
who
signs
the
block
will
make
sure
the
other
one
doesn't
double
sign.
It
I,
don't
really
recall
the
full
details,
but
I
remember.
E
I
Is
that
what
you're
talking
about?
No?
No,
no,
it
was
producer
signatures.
I,
think
I
know
what
you're
talking
about.
But
this
is
something
else
I
believe
there
was
an
ability
to
when
you
wreck
produce
or
something
to
I
forgot
exactly,
but
there
was
a
way
to
provide
multiple
keys
and
then
you're
able
to
you
know,
configure
different
machines
with
them.
E
H
H
Just
another
note,
there's
so
much
stuff
in
in
leap:
five
that
we
are
going
through
and
just
trying
to
create
notes
on
all
all
the
features
that
have
been
put
in
there
and
it's
so
much
that
it'll
probably
take
us.
You
know
months
just
to
roll
out
the
communications
about
the
improvements
and
everything
we've
updated
as.
H
E
The
required
config
changes
versus
the
recommended,
config
changes
and
I
say
that,
as
this
is
the
bigger
conversation
we're
having
and
yeah,
it
works
like
a
champ
if
you
disable
reversible
block
DB
size,
because
the
deforo
doesn't
like
that.
But
oh
yeah,
your
API
doesn't
respond
with
send
transaction
to
or
get
status
or
any
of
that
unless
this
and
this
and
this
and
this
and
this
and
this
are
flipped
on
so
those
types
of
things
anyway.
E
Oh
I
wasn't
aware
of
that:
the
difference
between
what
it
takes
to
Just
Launch,
the
damn
node
different
from
Boro.
You
know
config
change
versus
all
these
new
features
and
all
these
new
options
and
default
settings
that
may
be
a
little
too
aggressive
or
whatever
right
so
Ross
and
I
have
been
chatting
and
I've
been
trying
to
collect
a
bunch
of
the
different
VPS
configs
and
say
what
all
do
you
have?
Why
did
you
set
that
if
you
even
have
a
clue
why
you
may
have
just
copied
it?
That's
cool,
no
judgment,
all
right.
E
What
the
hell
do
we
really
do,
and
why
do
we
do
it
and
then
even
knowing,
when
do
you
need
to
enable
that?
Are
you
going
from
three
to
four?
Well
then
this
and
this
and
this
and
this
came
out
and
these
you
need
to
turn
on
so
that
Matrix
we
always
kind
of
talked
about
and
then
like
I,
say,
I,
hear
5-0
and
I
added
a
5-0
column.
So
when
I
start
hearing
some
of
these
new
features
not
requirements
almost
so
to
say
right.
H
E
It's
this
protocol,
and
and
all
of
that
I
mean
yeah
by
no
means
holding
you
to
it,
but
yeah
yeah
I
mean
there's
going
to
be
things
that
you
either
need
to
add,
or
should
maybe
add,
and
try
to
kind
of
assimilate
all
that
to
then
be
able
to
even
for
just
ourselves
going
damn
I
got
to
go
from
three
to
four,
oh
yeah.
This
is
a
setting
that
showed
up.
This
is
a
setting
that
showed
up.
This
is
what
we
all
kind
of
agreed.
E
C
H
E
Crazy
ones
out
there
gym
mentalities.
One
is
that
you
should
learn
it
on
your
own
and
play
with
them
all
and
break
and
see
how
it
works
and
the
other
is
you
know
that
if
you
just
copy
and
paste
configs,
you
never
know
what
they
are
and
it's
valid
I
mean
there's
a
lot
of
people
that
have
myself
included.
I,
don't
even
know
what
some
of
these
settings
that
I'm
running
are,
but
I
can
tell
you.
E
Somebody
said
that
problem
will
be
fixed
by
that
issue,
but
being
able
to
kind
of
Wade
your
way
through.
All
of
those
understand
what
they
are
what's
expected,
what's
required,
like
I
say
the
biggest
thing
is,
in
my
opinion,
things
have
become
optional,
which
is
good,
yeah
versus
things
becoming
well.
C
E
That
would
be
able
to
offer
better
API
services
to
the
users
consuming
our
service,
that
kind
of
stuff.
That's
what
we're
trying
to
I
want
to
turn
on
the
cool
new
features
that
that
you
know,
I
wasn't
sure
that
I
needed
usually,
and
he
puts
things
on
when
it
tricks
or
something
for
a
specific
reason,
and
that's
why
I
said
it
would
be
great
if
we
had
these
little
updates.
E
B
E
I,
just
don't
I
don't
want
to
miss
a
chick
right,
I
mean
sure
nothing's
broken
everything's
working,
but
you
know
there's
some
benefits
to
Turning.
Some
things
on
and
I
know.
Matthew
is
pretty
good
at
doing
that.
He
tends
to
actually
really
battle
test.
All
of
the
new
features
as
they
come
out,
I
mean
I
can
tell
you
what
he
tells
me
to
do.
E
He
just
prints
the
file
out
and
then
goes
one
by
one
and
I'll
probably
do
the
same
thing:
I'll
print
out
four,
oh
print
out
five
I
would
do
a
diff
on
it
and
say
I.
What
are
the
new
ones
that
show
up
in
here
but,
like
I,
say
it's
so
hard
and
even
you
know,
the
one-liner
descriptors
y'all
give
here's
what
it
does.
Well,
what
recommend
it?
Oh
on
a
public
API
ten
times
that
well
y'all,
can't
say
that
you
know
I
mean
we.
E
You
know
where
do
you
usually
get
that
so
anyway,
we're
working
on
trying
to
get
all
that
and
decipher
what
the
hell
some
of
these
things
even
are,
but
looking
forward
to
as
new
features,
you
know
and
Kevin
does
a
good
job
of
well
I
can't
tell
you
what
to
do,
but
this
is
what
what
you
like,
yeah,
hey
I,
feel
like
we're
having
a
groundhog
meeting
this
last
15
minutes
is
the
same
meeting
I.
Do
that
it's
a
meetings!
I'm,
sorry.
A
A
A
How
do
we
prepare
for
this
from
what
I
understand?
This
is
only
impacting
top
21..
Is
that
right,
these
the
changes
in
how
we
operate
with
these
new
signing
keys,
app
Developers,
node
operators
that
are
not
within
consensus,
not
as
impacted,
obviously,
except
for
when
they
become
inconsensus?
So
you
know
maybe
something
that
top
30
need
to
be,
in
particular,
paying
attention
to.
D
D
It
may
be
other
other
issues
there,
but
certainly
in
the
future,
we're
at
least
contemplating
separating
out
block
finalization
from
block
production,
and
so
we
would
look
to
have
separate
keys
there
for
for
those
now
again,
potentially
they
could
be
the
the
same
key
I
guess
if
you're,
if
you're
doing
both
but
yeah
I,
don't
have
an
answer
right
now.
Why
or
if
BLS
Keys
could
be
reported
to.
D
So
so,
and
the
the
new
consensus
mechanism-
there's
distinction
made
between
so
in
the
current
consensus
mechanism-
there's
a
combination
of
of
things.
If
you
will
there
is
the
the
block
production,
there's
the
the
block,
validation
and
the
block
finalization
or
for
a
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.
D
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
until
there's
a
distinction
here
between
that
validated
a
block.
That's
a
posted
I'm
I'm,
actually
producing
a
block,
and
we
can.
D
We
could
definitely
even
discuss
now
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
those
two
rows.
E
D
It's
the
same
way
that
it
is
today,
if
you
will
so
a
BP
will
be
playing.
If
you
will
multiple
roads,
they
will
be
both
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,
the
who
is
playing
the
leader
in
the
consensus
algorithm
that
which
could
also
be
separated
out
the
currently
the
leader
is
following
the
block
producer.
Now
that
could
be
changed
in
the
future
as
well.
D
We
could
keep
a
leader
active
until
for
whatever
reason
they
go
down,
we
could
have
a
leader
either
followed
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
of
those
three
concepts
can
be
completely
separated
in
the
new
consensus.
Algorithm
now,
I
think
the
first
thing
for
5.0
those
will
all
be
combined
in
in
the
block
producer.
I
D
D
The
other
kind
of
really
cool
thing
about
the
new
algorithm
is
like
we
could
now
again
none
of
this
in
5
volt,
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
Mill
block.
D
We
could
say
hey
this
block
producer
is
down,
let's
switch
to
and
I'll,
let's
switch
to
a
backup
and
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.
So
there's
kind
of
really
cool
here
that
can
happen
or.
E
D
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
of
where
we
can
go
and
to
even
a
a
more
robust
system
than
we
have
today.
A
D
Yeah,
that's
a
really
good
question.
It
would
be
the
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
ultimately
are
going
to.
You
know
approve
of
the
blocks,
but
presumably
that
row
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.
A
D
Mean
the
ultimately
a
validator
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
what
would
be
the
term
to
to
to
have
an
opinion
about
that
right,
so
yeah,
so
it
would.
It
would
be
the
the
BP's
student's
job
it
would
be
to
to
go
to.
A
Find
out
now
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?
A
E
E
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
and
I
here's
what
you're
expected
to
set?
E
E
Is
that
actually
the
case?
Or
can
we
move
a
key
one
to
the
other?
That's
what
I
say:
I
mean
without
knowing
for
sure
but
I
that
I
don't
know
how
disruptive
that'll
be,
but
it's
probably
disruptive,
hey
you've
got
a
new
thing
to
manage
and
B.
It
sounds
like
it's
not
the
same
logic,
I.
Think
the
answer
to
the
question.
There,
then,
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?
E
E
Some
type
of
you
know
mechanism
like
that
correct,
yeah,
I,
don't
know
if
it
requires
or
just
piggyback
on,
because
that
also
thought
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.
But
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?
E
E
The
permission
of
the
doing
this
node
transfer
needs
to
be
different
than
the
person
who
has
the
key
to
run
the
block
producer,
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.
E
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.
Yes,
let's
see
how
it
goes.
Let's
see
what
you
come
up
with
I'm
happy
to,
if
there's
a
magic
under
the
hood
draft,
that
I
need
to
keep
my
mouth
shut
about,
happy
to
look
at
it
and
give
you
some
feedback
and
whatever
that
would
help.
H
H
C
If
not,
I
was
going
to
hop
in
in
chime
in
just
on
the
topic
of
feedback
here
recently,
Jonathan
gisek
did
just
merge
in
a
PR
related
to
some
of
the
P2P
improvements
that
are
working
in
the
background.
So
if
anybody
has
some
idle
time
and
wants
to
provide
feedback
on
the
current
metrics,
we're
reporting
on
to
date,
that'd
be
definitely
valuable
prior
to
the
release.