►
From YouTube: Node Operator Roundtable - March 1, 2023
Description
This week the EOS Node Operator Roundtable updates the community on software development and continues the technical discussion on special node types, focusing on Block producer nodes.
00:00:00 Start
00:00:02 Recap and this week's topics
00:00:30 Software development update
00:05:28 Special nodes technical discussion
00:06:41 Resource Provider nodes
00:09:49 Best practices for node types
00:11:06 History Provider node
00:26:25 Block Producer node
00:54:09 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
All
right
welcome
everybody,
it's
March
1st
and
we're
continuing
the
discussion
today.
I
think
now.
This
is
the
fourth
fourth
day
where
we're
we're
going
into
special
purpose
nodes:
lots
lots
to
unpack
they're
still
so
we'll
continue
that
conversation
before
we
get
into
that
I'll,
throw
it
to
Stephen.
If
there's
any
updates,
you've
got
to
share
as
it
comes
as
it
pertains
to
the
leap
software
update
status.
B
B
B
B
B
D
C
D
B
C
E
A
F
F
F
All
right,
if
not,
then
we
can
move
into
resource
provider
nodes
at
the
moment.
I
I
have
this
categorized
as
kind
of
a
layer
two
thing.
So
the
first
thing
I'm
going
to
ask
is:
is
this
is
indeed
kind
of
a
layer,
two
sort
of
solution
or
would
you
it
is
okay,
cool
and
is
it
in?
Would
we
call
it
a
node
or
is
it?
Is
it
just
a
service.
E
It's
I
would
say
it's
comparable
to
something
like
compute
transaction
endpoint,
where
it
provides
a
service
based
on
node
information.
There's
additional
business
Logic
on
top
of
it.
But
it
is
directly
like
it's
in
the
push
transaction
flow
because,
like
compute
transaction,
just
like
yeah
things
like.
F
That
all
right
yeah,
that
makes
sense,
so
it
has
to
actually
be
directly
processing
that
I'll
leave
the
terminology
as
nude
for
now
all
right
and
I
think
I
think
Aaron
drafted
this
initial
language
here
so
Aaron.
Do
you
want
to
kind
of
give
the
the
quick
overview
of
of
this
resource
provider
node
definition
sure.
E
E
The
transaction
is
passed
to
this
node
or
this
service,
whatever
we
want
to
call
it
and
it
is
evaluated
for
issues
and
if
issues
in
terms
of
resources
are
detected,
it
returns
a
modified
transaction
to
the
client
based
on
its
recommendations
of
what
could
be
changed
to
resolve
those
resources
choose
and
that
the
user
can
accept
it
or
if
it's
it's
validated
and
automatic
that
in
the
user
side.
So
that's
just
a
normal
transaction
at
that
point,
but
it
is
a
user
experience
and
answer.
E
F
E
F
All
right,
so
I
think
that
that
sort
of
takes
us
through
the
the
list
of
identified
node
types
sort
of
next
steps
that
I
have
captured
here
are
to
go
into
capturing
best
practices
for
each
of
these
node
types,
so
we
can
kind
of
hop
back
up
to
the
beginning,
at
least
for
the
ones
we
haven't
started.
Talking
about
that,
so
you
know
what
are
the
device
requirements
for
it?
You
know
as
like
yeah.
This
needs
a
lot
of
Hardware
or
a
lot
of
disk.
This
needs
a
lot
of
ram
this.
F
You
know
those
sorts
of
things:
nodeo's
configuration
best
practices
with
regards
to
things
like
chain,
Epi
producer,
API
and
that
API,
you
know
all
of
these
sorts
of
things
and
then
network
configuration
best
practices
and
I
should
maybe
to
distinguish
this
I
should
say
networking
I'm
talking
about.
Like
you
know,
oh,
you
should
put
a
load
balancer
in
front
of
this
right,
like
those
sorts
of
things
so
before
we
like
hop
into
doing
that.
F
C
Well,
I
have
a
question
on
History
through
it
there.
So
your
history
comes
in
many
forms
and
Fashions.
So
are
we
just
gonna
leave
a
general
statement
or
we
wanted
to
break
that
down
more
into
you
know
kind
of
like
full
history
of
everything,
specific
history
of
like
just
account
token
balance,
or
you
know,
like
history,
yeah.
F
C
Potentially,
okay
I
did
not
really
have
anything
specific
in
mind
it
just
it
seems
like
history
is
a
big
topic
and
we
have
like
one
sentence
so
right
that
the
right
level
of
detail
you
are
because
if
you
want
to
get
into
like
API
sizing
and
how
much
space
it
takes
and
compute
well
depends,
you
know
what
you're
doing
with
your
history
solution.
The
answer
is
very
different.
It
could
be
you
know,
terabytes
of
Ram,
or
you
know
five
gigs
yeah.
This.
C
I'm
gonna
start
with
maybe
the
first
one,
which
is
the
Aaron,
give
me
the
details
here,
but
the
API
that's
part
of
node
EOS.
Well,
there's
like
get
Block,
which
is
kind
of
a
history
thing,
get
a
block
any
Block
in
the
past
and
then
there's
the
get
accounts
which
Returns
the
you
know.
The
list
of
tokens
or
Muslim
accounts
available
for
a
given
key
get
actions.
E
C
C
C
Token
and
stuff
are
those
current
state
because
they're
very
specific
to
the
implementation
of
the
system
contract
that
you
chose
or
I'm
getting
two
foot
fill
assault
right,
so
there's
ways
of
organizing
the
data
in
the
current
state,
which
requires
history
in
order
to
generate
that
state.
So,
for
example,
give
me
the
list
of
all
the
tokens
that
this
account
owns
or
give
me
all
the
users
who
own
this
token.
That's
current
state,
but
it
needs
a
whole
lot
of
history
in
our
degenerate
and
nobody
else
doesn't
track
that
right.
C
D
Yeah
and
then
you
also
have
like
get
to
cap,
get
account
by
authorizers,
which
is
available,
but
only
if
you've
been
able
the
queries
option.
You
know
so
and
then
also
in
in
the
next
release.
You
know
we're
gonna
have
well
off
already
and
three
one
you
have
block
lock
pruning,
but
in
in
4-0
you
don't
have
lock
lot
splitting
and
ship
lock
splitting,
and
so
you
know
again
watch
your
definition
of
current
if
you're,
not
keeping
all
of
those.
A
E
I
think
for
the
context
of
this
bullet
point
it's
anything,
that's
not
current
is
what
we
would
deem
history,
but
the
the
get
accounts
by
authorizers
and
the
balance
stuff.
Those
are
those
are
still
current
state
they're
updated
in
real
time
and
there's
nothing
historical
about
them.
They
are
derived
state.
E
F
D
D
F
E
F
C
Know
it's
all
that
there's
there's
current
state,
that's
calculated
by
node
us
and
there's
a
current
state,
that's
calculated
by
external
tools
right,
so
there's
two
ways
of
getting
current
state
and
then
there's
historical
state
which
you
know
has
to
do
with
something.
That's
in
the
past.
It's
not
heard,
which
you
know
node
us
provides
you
know
ship
or
to
blocks
log
and
there's
external
tools
that
provide
get
transaction
or
you
know,
Trace,
history
or
I
guess
stress
issues
built
into
the
us,
but
you
know
so.
F
So,
just
to
clarify
I
think
what
you
said
here:
Matthew
is
basically
a
more
precise,
restatement
of
what
I
had
as
like
Raw
versus
derived
it's
so
it's
state
calculated
by
nodeeos
versus
State,
calculated
by
external
tools
there.
That
would
be
the
same
thing
but
more
precisely
stated
as
Raw
versus
derived
right,
I.
E
F
F
C
And
I
mean
if
you
want
to
slice
them
Less
in
a
different
way.
There's
you
know
also
generic.
You
know
apis
that
allows
you
to
build.
Oh,
my
gosh
Accenture,
but
allows
you
to
build
custom
queries
to
do
like
kind
of
whatever
you
want,
like
you
know,
graphql
or
something,
and
then
there's
other
things
that
are
very
specific.
Well,
you
can
just
query
this
thing
in
this
pattern.
C
E
But
the
line
above
it
the
event
capture
Services.
They
feed
these
kinds
of
solutions,
regardless
of
what
they
do
and
there's
a
variety
of
things
that
they
can
do
like
we're
talking
from
history,
Solutions
like
hyperiorated
Robo
to
the
atomic
assets
API
to
the
light
API
to
even
fire
hose
technically,
it's
like
fire
hose
is
a
capture
service,
and
then
it
feeds
it
right
back
out,
but
yeah,
which
is
fine.
F
F
A
F
I
don't
know
if
this
is
a
helpful
exploration
or
not,
but
another
thing
I
was
just
thinking
about
is
like
what
are
the
use
cases
for
the
State
history,
data
itself
and
I.
Don't
know
if
these
statements
make
any
sense,
but
one
is
like
to
verify
the
I
just
came
up
with
an
arbitrary
term
here,
but
the
canonicity
of
state
right,
like
is
this,
the
the
like
verifiable
deterministic
State
at
a
certain
point
right.
F
Another
is
like
retrieving
preconditioned
data
for
for
building
a
action
as
part
of
a
transaction
right
like
I
need
to
know
what
the
data
is,
so
that
I
know
what
I
want
to
do
in
an
action
I
like
as
a
as
an
app.
If
that
makes
sense,
does
that
make
sense?
Or
does
it
sound
like
I'm
rambling,
like
a
crazy
person,
I'm
careful.
A
E
Ahead,
I
was
gonna,
say,
I
think
to
Loop
all
the
way
back
to
the
next
goal
of
classifying
these
in
terms
of
requirements
this
one
just
unless
it's
broken
out
into
individual
Solutions,
it's
most
likely
not
going
to
be
able
to
be
classified
because
each
solution
requires
different
requirements
like
different
Hardware
requirements.
Yeah.
F
C
E
F
F
F
E
C
E
I
would
almost
say
the
producer
and
then
the
producer
becomes.
This
is
more
what
I'm
gonna
mention
is
more
of
like
a
methodology.
It's
doing
this
yep,
the
like
whatever
we
deem
the
bare
minimum,
is
the
Baseline
and
then
other
Solutions
are
either
above
that
or
below
that,
or
you
know,
because
the
minute
we
start
talking
about
EOS
versus
wax
versus
Telos
versus
a
test
net.
Like
you
know,
we
can
no
longer
give
numbers
like
I,
can't
say
this
much
RAM.
E
F
Yeah,
that's
an
interesting
point.
So
is
it?
Is
it
worthwhile
to
attempt
to
capture
device
requirements
because
I
guess
what
you're
saying
is
there's
different
categories
here,
there's
like
are:
are
we
running
this
on
a
on
a
main
net
or
a
test?
Net
I
will
try
to
network
right
like
a
single
node
type
of
network
and
then
there's,
as
you
said,
even
within
that
different
different
main
Nets
right
might
have
different
requirements.
F
C
D
C
F
F
F
F
F
C
B
C
C
C
F
F
E
F
C
F
A
F
C
F
F
E
F
B
F
Okay,
all
right
nodes
configuration
best
practices
now,
I
I,
don't
know
if
it
actually
makes
sense
to
sort
of
break
this
into
chain.
Epi
producer,
API
net
API,
DB
size.
You
know
all
those
sorts
of
things.
So
that's
the
first
question
is:
does
it
make
sense
to
run
through
the
different
sort
of
plug-in
level
things
for
how
we
configure
it,
or
is
it
more
just
one
running
list
of
best
practices.
F
F
F
C
The
the
really
the
the
best
practice
that
I
know
of
is
make
a
signing
key,
that's
specific
only
to
sign
a
right
so
that
you
it
doesn't.
It
can't
be
used
for
something
else.
So
therefore,
it's
you
know
isolated
to
just
put
it
on
a
server,
that's
isolated
from
everything
else
as
much
as
possible
and
just
make
you
specific
as
possible
for
signing
below.
C
C
B
F
F
C
E
F
C
Yeah,
so
in
our
block
producer,
the
chain
API
is
enabled
because
we
need
to
do
monitoring
for
get
info.
Otherwise,
it's
not
you
just
producer
API
is
enabled,
so
we
can
update
the
block
list
or
whatever
as
needed.
The
net
API
is
always
enabled,
isn't
it
and
the
DB
size
API
is
always
enabled
well
in
our
case.
C
C
F
C
F
This
is
crossing
out
of
the
boundary
of
like
configuration
best
practices
of
today
a
little
bit,
but
just
so
that
I
can
capture
it
and
sort
of
re-organize
later
for
each
of
these,
can
we
capture
like
why
you
have
it
enabled
and
what
you
wish
didn't
come
with
it
for
this
particular
type
of
nude?
If
that
makes
sense,
sure
So,
like.
C
E
D
F
F
B
C
A
C
So
okay,
because
this
is
an
internal
thing,
why
do
it
like
the
chain?
Api
is
meant
for,
like
public
consumption
kind
of
think
about
it
like
this
is
my
for
me,
my
node
operator
monitoring,
or
at
least
that's
how
it
so
when
we
publish
the
list
of
available
API
endpoints
to
the
public,
we
review
this
one
from
the
list
and
we
block
it
from
the
proxy.
The
operation.
F
F
C
F
All
right,
Trace
API,
no,
it's
disabled,
so
it
doesn't
matter
yeah,
okay
and
ship,
also
disabled.
The
matter
do
not
snapshot
on
the
Block
producer,
so
it
doesn't
matter.
Okay,
other
networking
configuration
best
practices,
kind
of
I.
Guess
this
kind.
There's
a
blurry
line
between
here
where
we
talked
about
like
blocks
only
relays,
public
and
preferred
stuff,
because
some
of
that's
probably
implemented
via
networking
right
or
is
that
all
just
configuration
stuff.
C
And
it
feels
like
a
useful
little
exercise,
but
I'm
gonna
get
this
written
down
because
I,
don't
I
think
this
is
in
like
the.
What
do
you
call
it?
Og
block
producers
as
and
it's
not
written
down
anywhere
and
I
see
you
know
every
time
there's
a
new
block
producer
they're
like
but
nothing's
I,
don't
know
and
like
they're,
just
all
confused,
because
none
of
this.
F
Well
and
I
also
think
it'll
be
valuable
over
time
to
like,
as
we
get
through
other
types
of
nodes,
we
can
start
to
tease
apart
the
features
of
the
different
plugins,
for
example,
and
when
they
are
and
aren't
desired
by
different
nodes,
and
it
might
actually
lead
to
architectural
changes,
not
just
recommendations.
You
know
so
anyway,
cool
all
right,
Daniel,
you
can
take
the
mic.
A
All
right
thanks,
Brian
I,
have
nothing
to
add.
It
was
great
great
discussion,
I
plus
Solana,
it's
great
to
see
the
this
knowledge
coming
out
of
the
heads
of
of
our
OG
node
operators
and
the
enf
taking
an
active
interest
and
making
sure
that
we're
architecting
this
software
in
a
way
that
makes
sense
to
the
way
that
we
operate
it.
So
that's!
It's
awesome,
awesome
progress
here
and
with
that
I
think
we
can
wrap
things
up.