►
From YouTube: Node Operator Roundtable - March 8th, 2023
Description
This week the EOS Node Operator Roundtable updates the community on software development and continues the discussion on Special Nodes, focusing on configuration best practices.
00:00:00 Start
00:00:03 Software development
00:01:06 Special Purpose Nodes technical discussion
00:03:37 Wire Guards
00:20:20 Configuration best practices
00:56:11 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
B
We're
really
just
kind
of
closing
in
on
all
of
that
stuff.
Part
of
this
is
also
attributed
something
that
I'll
celebrate,
which
is
that
we've
actually
ratcheted
up
a
little
bit
of
the
process
by
which
we
actually
accept
things
being
merged
in
and
that's
been,
what's
caused
a
little
bit
of
this
Log
Jam,
so
just
got
some
natural
Growing
Pains
there,
but
we're
still
on
track
with
our
March
April
release.
A
A
A
C
We
talked
a
little
bit
about
networking
configuration
best
practices
for
those
nodes
and
security,
best
practices
and
I
believe
we're
on
to
the
block
Zone.
We
relay
nodes
configuration
best
practices
now
before
we
jump
into
that.
Were
there
any
sort
of
last
thoughts
on
the
Block
producer
nodes
configuration
I.
A
C
C
D
So
unless
you
have
the
wire
guard
key
to
connect
to
the
peer-to-peer
Network,
then
you
can't,
you
know,
make
a
random
connection
to
the
the
peer-to-peer,
and
so
there
was
a
question
like
a
few
months
ago
back
it's
like
if
we
remove
the
peer-to-peer
key,
that's
built
into
node
us.
Would
that
have
an
impact
I
said?
Well,
we
use
it,
but
it
doesn't
really
have
anything
back
because
in
our
environment
we
need
a
wire
guard
key
and
we
need
to
know
USB.
D
D
You
know
you
can't
stop
your
outside
connections
once
they
kind
of
know
you're
there
without
having
that
kind
of
gate,
key
to
say
no
you're
not
going
to
be
accepted
as
a
peer-to-peer
inbound
either.
That
makes
sense
so
I
mean
it
was
in
cases
like
we
were
rolling
back
chains,
but
it
was
the
only
mechanism
that
we
that
that
you
really
had
at
the
node
OS
level
versus
you
ufw,
where
we
do
it
at
our
Barbershop
like
well
yeah.
D
The
other
thing
I
know
Michael
you've
mentioned
is
you
know
you
need
to
check
some
kind
of
change,
the
port
that
node
us
is
listening
on
that?
That's
what
I
do
is
kind
of
an
extra
yeah
right.
I
I
have
done
the
same
thing
in
the
past
right
because
it's
like
all
these
people
are
trying
to
connect
you're
trying
to
re-sync
Pier
or
whatever,
and
it's
like
how
do
I
store
it
just
allow
some
connections
in,
but
not
the
right
one.
So
you
know
you
change
the
port,
then
change
the
port.
D
D
Let
me
just
connect
to
this
node
so
that
I
can
UNS,
freeze
the
tank
so
and
I
think
the
way
the
keying
on
peer-to-peer
words
I
mean
it
shouldn't
slop
off
anything,
that's
not
accepted
as
a
valid,
because
the
work
is
the
yeah
multi-processing
of
the
track
of
whatever
it's
getting
in
so
I
mean
that-
and
that's
I've
just
mentioned
a
use
case
over
the
years
that
well
it's
hard
when
you're
you're
the
peer-to-peer
Target
you
know,
and
then
you
don't
want
to
be
anymore
right.
No,
no.
C
D
No,
even
though
I'm
I'm
only
talking
to
one
peer-to-peer
to
try
to
get
the
most
efficient
process,
I
can
I've
got
five
other
nodes
that
are
still
pushing
peer-to-peer
yeah
and
if
it's
re-syncing,
it's
saying,
unlikable
block
I'm
like
well
block
unlikeable
block
you
key
peer-to-peer
is
so
efficient
at
keeping
trying
and
shoving
data
down
every
pipe
that
it
can.
What
we
end
up
doing
is
some
way
or
another
blocking
all
that
outside
peer-to-peer
traffic,
but
we
still
need
peer-to-peer.
You
know,
oh,
and
so
what
we'll
do
is
either
change
the
ports.
D
You
know
go
to
all
the
nodes
and
remove
it
is
up
here,
a
ufw
it
you
know,
block
IPS
whatever,
but
if
you
put
that
key
in
it
would
reject
anybody
that
you
didn't.
Does
that
make
sense?
The
best
practice
is
find
a
way
to
keep
everybody
else
out,
even
when
you
yourself
have
trimmed
your
list
down
to
one
because
it's
more
efficient,
you
forget
that
there's
15
inbound
connections
and
it's
just
crushing
you
and
you
can't
stop
yeah.
So
we
end
up
using
wired,
Earth,
so
water
down
the
interface
and
then
oops.
D
A
D
It's
awkward,
I'm,
not
sure,
there's
a
you
know
a
really
better
scenario.
If
you
enable
the
yeah
peering
key
I,
think
it
rejects
all
peers
that
don't
have
a
valid
key
which
nobody
does.
But
you
know
you
end
up
having
to
restart
node
us,
because
you
can't
insert
a
key
on
the
clio's
net
connect
command.
D
Yes,
but
that's
the
BP
node
yeah,
okay
and
we
do
in
most
load
balancers,
but
natively
aren't
aware.
You
know,
I
mean
if
it
sees
the
poor,
responding.
It's
shoving
traffic
down
at
both
API
and
peer-to-peer,
which
is
a
problem
and
I
can
see
it
all
the
time
that
behind
a
load,
balancer,
somebody's
replaying,
a
node
and
all
of
a
sudden
like
if
I'm
query
and
the
block
reducer
table
I'll
get
a
table
from
three
years
ago
and
I'm
like
oh
somebody,
load
balancer
responded
to
a
sinking.
D
No,
because
it's
a
you're
dying,
somebody
misconfigured
their
little
bouncer.
It
should
never
elf
check
to
check
that
the
node
is
in
sync
before
sending
in
so
to
answer
the
question.
We
do
use
load
balancers
but,
as
I
said,
natively
they're,
not
very
good
they're.
Just
doing
you
know
being
tasks
mostly
Stam
has
written
some
additional
tasks
and
I'm
sure
Matthew
has
some
as
well
that
you
can
try
to
suit
them
up
and
add
some
check
the
head
block,
his
checks,
the
head
block,
checks,
the
lib
and
says:
okay
everything's
good.
D
C
A
C
D
A
D
C
A
D
Right
because
the
resyncing
is
not
happening
in
like
less
than
two
minutes:
okay,
fair
enough
right
so
yeah
you
can
restart
a
node
in
less
than
two
minutes
and
like
typically,
if
I'm
doing
a
node
us
upgrade
I
don't
switch
to
black,
but
instead
I
just
wait
for
the
right
time
in
the
schedule.
Stop
the.
A
D
That's
how
a
lot
of
us
do
it
because
I
mean
that
goes
back
to
the
whole
concept
of
failover
and
backups
and
way
block
signing
worked
in
general.
It's
such
a
hassle.
It
takes
10
minutes
to
roll
to
a
backup
or
unregister.
You
know
I
mean
no.
You
shouldn't
have
to
unregister
just
simply
to
do
maintenance,
fun,
Quirk,
that
several
people
on
chains
have
gotten
burned
by
when
you're
unregistered
people
can't
renew
their
votes
for
you.
So
people
find
they
go
down
for
maintenance.
A
whale
went
to
co-renew.
D
A
D
D
D
D
D
I
tend
to
do
for
simplification,
because
there's
so
many,
my
peer-to-peer
layers
are
all
respectively
to
it
themselves
and
outbound
public
and
handling
all
the
the
ins
and
outs
as
well
as
private
and
public
connections.
And
then
all
my
supporting
nodes
are
basically
peer,
three
peers,
plus
maybe
public,
if
they're
getting
it
that
ultimately
are
relaying
back
to
my
my
peer-to-peer
layer.
D
So
I
don't
do
bi-directional,
because
I'd
have
to
go
to
50
dagger
machines,
I,
basically
built
this
solid
peer-to-peer
match
and
all
of
my
nodes
kind
of
star
in
the
head,
but
there's
three
of
them,
so
it
I
could
read
one
or
two,
and
ultimately,
all
these
have
an
active
Pier
that
everything
else
is
still
tied
to
as
well.
And
then
it's
a
main
gateway
out.
C
B
D
I
am
looking
forward
to
seeing
how
that
works.
Have
you
guys
done
any
testing
under
under
load?
Like
can
you
replicate
scenario
but
wax
has
had
over
the
last
couple
of
months
where
you
know
somebody
is
pushing
huge
number
of
transactions,
another
block,
it
gets
pear-shaped
like
the
transactions
go
up
up
and
then
all
of
a
sudden
that
blocks
all
get
lost
all
right
and
we,
the
runner
with
3.1
and
then
run
that
same
recording,
oh
and
see
if
it
fixes
it.
D
C
D
C
C
D
So
we'll
say:
where
does
the
recommendation
for
only
10
in
peers,
no
problem,
I
would
say
if
I
had
to
guess.
In
my
conversation,
I
mentioned
that
I'm
up
here
to
peer
mesh
I
tend
to
use
10
to
15.,
just
as
make
sure
because
I
mean
they're
always
going
down
up
there,
whatever
I,
don't
I,
try
to
break
it
up
and
build
I,
don't
let
50
in
one
note
you
know
what
I
mean
right,
but
you
have
make
it
distinguish
between
a
blocks.
D
Only
peer-to-peer,
node
and
a
transactions
plus
block
spirit
I
make
that
distinction
when
I'm
setting
up
the
node
based
off
of
its
role,
but
that
I
I'm,
just
mentioning
in
my
in
my
opinion,
that's
probably
where
that
number
came
from
is
my
mentioning
on
my
Publix
and
my
privates
I.
Try
to
pull
it
up
everything
I'm
connecting
to
about
having
more
than
10
or
15
Max.
D
Dozens
of
public
requests,
I
can't
bro
I
mean
unless
I'm
going
to
hard
tap
at
it.
You
know
it
is
what
it
is,
but
I
was
just
providing
a
context
if
I
had
to
guess
where
that
number
came
from.
That's
why
I
said
those
numbers
yes,
I
would
I
would
agree
with
that.
Then
right.
So
the
number
configured
is
in
the
10
to
15
range.
The
numbering
you
accept
is
higher
than
that
right.
You'll
find
your
limit
verified
it
for
you
and,
like
I
said
it
could
be
high.
B
D
Wax,
which
is
next
level
I've
done
more
than
100
before,
but
yeah
I
try
to
keep
it
more
like
the
75
range
years
and
that's
total.
So
you
know,
wherever
kind
of
getting
you
two
distinction.
The
number
you're
on
right.
There
is
what
we
would
configure
in
the
Big
File,
okay,
but
no
more
than
75-ish
is
the
recommendation.
D
Config
file
individually
listed
Nations,
Aloha
Sweden,
USC,
USA,
olives,
right
yeah,
but
then
Matthew.
You
know
he
was
asking
for
clarification.
Obviously,
that
note
can
handle
way
more
than
that.
We
intend
to
try
like
if
you're
hosting,
public,
peer-to-peer
or
inbound
peer-to-peer
traffic
look
after
about
75
or
more,
it
really
starts
to
kind
of.
You
should
put
another
node
in
that
ballot,
so
you
should
cut
it
Target
for
less
less
than
that,
and
let's
say
some
of
the
25
some
up
on
50,
but.
D
It
I
can't
say
in
the
recent
past,
I've
really
pushed
it
to
know
on
on
a
general
level
like
that,
I
mean
I'll,
throw
you
know,
eight
net
threads
or
something
at
it
and
I
mean
it'll,
be
fine.
What
I
typically
more
find
is
the
more
connections
it's
handling,
the
more
likely
that
it
gets
jammed
up
whenever
I
need
to
be
boot,
it
or
you
know,
upgrade
it
or
something
like
that.
That.
E
Also
should
be
fixed,
infor
I
know
we
have
a
different
shutdown
procedure
that
should
make
shutdown
immediate
well
minus,
like
if
you're
running
chain
Basin.
It
has
to
do
its
thing
to
write
out,
but
in
terms
of
like
a
10
000
transactions
queued
up
that
it
thinks
it
has
to
chew
through
that
should
be
greatly
improved
in
for
all.
D
Yeah,
so
to
answer
Kevin's
question:
I
haven't
done
any
recent
performance
testing
to
see
you
know:
hey,
can
we
run
200?
Does
it
make
sense?
Is
it
reasonable,
not
sure
maybe
I
mean
there's
been
a
lot
of
improvements
since
I
last
tested
this
probably
in
like
2.0
or
something
I,
wouldn't
say
absolutely
because,
like
I
say
I'm
pretty
sure
Ross
said
he
got
like
200
and
he
just
get.
You
know
on
his
peer-to-peer,
but
he's
throwing
big
Hardware
at
it.
You
know
and
God
I
can
only
imagine
how
much
traffic
it
is.
E
My
thought
there
would
be
that,
like
the
node
ought
to
be
able
to
handle
pretty
much
whatever
you
could
throw
at
it,
that
the
the
bottleneck
is
going
to
be
the
fact
that
you
know
unique
transactions
into
the
node
right.
The
more
connections
you
have,
the
more
likely
you
are
to
get
unique
transactions
at
some
point,
there's
a
threshold
of
of
what
possible
process
in
terms
of
unique
transaction,
but.
A
D
A
D
What
it
sounds
like
and
I,
don't
know
the
ratio,
but
the
number
of
threads
total
on
the
machine,
because
it's
obviously
doing
some
other
things
as
well,
then
the
number
of
defined
chain
threads,
which
is
a
param
in
for
node
OS,
and
that's
what
is
probably
handling
all
these
connections
and
then
there's
probably
a
correlation
between.
If
you
have
eight
net
threads
and
enough
other
threads
to
do
the
rest
of
your
work,
you
could
probably,
with
a
standard
processor,
handle
20
threads
of
relaying
blocks
per
thread
times.
E
So
what
what
happens
there
is
that,
if
you're,
just
talking
black
about
block,
relay
and
change
direction,
producing
stories
aren't
really
going
to
do
anything
they're.
Just
you
on
a
block
only
to
just
do
the
the
block
header
valid
things
for
validation
and
then
for
a
block.
It's
doing
signatures
for
validation
on
all
the
transactions
in
that
block,
but
you
know
there's
only
there's
only
one
like
it
doesn't
do
it
for
every
block
that
comes
in
it's
just
doing
it
per
block
of
a
unique
block
right
so.
D
If
that's
the
only
work
that
it's
doing
right,
I
mean
the
holidays
right,
maybe
500
connections
per
thread
But,
ultimately,
wouldn't
that
be
the
the
however
many
threads
you
have
that
can
handle.
However
many
maximum
per
thread.
That
would
what
you
could
use
to
find
your
maximum
period,
because
it's
not
having
anything
so.
E
Block
only
the
net
trades
are
going
to
be
the
the
most
important
thing,
the
other
part's
going
to
give
you
much
benefit
for
an
API
node
or
a
relay
node,
that's
doing
transaction,
then
the
actually
in
our
performance
testing.
One
of
the
things
we
found
is
the
the
best
one
to
increase.
Is
the
producer
a
thread
count
surprisingly.
The
chain
one
didn't
seem
to
make
much
difference,
but
in
griefing
the
producer
one
made
a
significant
difference
in
performance.
D
And
then
yeah
interesting
beats
is
touched
on.
The
second
beating
screw
now
unblock
all
the
relays.
You
would
think
you
bump
up
your
chain
threads,
but
no
I
thought
they
could
produce
your
parents,
but
I
guess
we'll
get
to
that.
But
if
that
makes
sense
related
with
pieces,
so
I
I
think
the
the
problem
node
us
can
handle
more
than
we're
currently
configured
to
throw
at
it
right.
Definitely
in
blocks
only
relay.
C
D
D
You
need
more
than
one
because,
like
I've
seen
that
people
like
oh
I,
just
connected
this
relay
and
then
they
take
the
relay
down
for
maintenance,
then
their
locker
is
just
not
personal.
Well,
hello,
our
connective
Network
right.
So
you
have
to
look
at
your
topology
redundancy,
failover
or
strategy
between
data
centers
and
stuff.
So
you
end
up
probably
running
more
than
one
anyway
right,
if
you're,
if
you're
doing
that
higher
Bill.
E
C
D
Say
a
reliable
internet
connection
yeah
and
even
that's
a
disk,
because
I've
seen
both
of
those
have
effects
that
it
kind
of
results
as
lag.
It
can't
get
the
blocks
in
you
know,
I
mean
as
fast
as
it
needs
to.
Therefore
they
keep
getting
latency
added
as
well
as
leaving
saw
some
discs
that
you
know
it
was.
The
state
DB
probably
was
just
ripping
on
the
disk
and.
D
D
Okay,
that's
introduced
the
automatic
the
expiry
to
get
rid
of,
because
the
the
reason
that
these
nodes
exist
is
to
improve
the
peering
between
the
block
producers,
not
as
a
general
dear
public.
Please
connect
here
and
get
your
blocks
right.
Ironically,
we've
gone
the
other
way.
I've
just
recently
made
a
push
to
push
all
full
block
logs
to
I
mean.
D
Obviously,
my
state
histories
were
first
peer-to-peers
and
apis
as
well,
because
now,
as
I'm
syncing
nodes,
remember,
my
peer-to-peer
network
is
my
source
of
the
chain,
so
I
can
use
all
three
of
us
peer-to-peers
from
Genesis
all
the
way
through,
because
I'm
resyncing
the
chain
more
than
you
would
think.
You
know.
D
Because
I
need
to
respond
to
Matthew's
get
Block
one
request.
Ship
nodes
obviously
need
full
logs
because
you
know
I
mean
most
of
those
layer.
Tutors
want
District
or
or
not.
Maybe
once
you've
loaded
the
data
into
Atomic
assets,
you
don't
need
the
data.
What
I
actually
did
it
ends
it
that
way
what
I
did
to
start
with
was
kept.
It
trimmed
because
you're
right
as
I
marched
forward,
you
don't
have
to
retain
the
old
logs.
D
Some
of
those
nodes
handle
public
requests.
Some
of
those
nodes
handle
private
requests.
Some
of
those
nodes
handle
internal
requests
or
connections.
Does
that
make
sense,
but
all
of
them
for
the
same
reason,
have
full
logs
if
any
of
the
public
peer-to-peers
need
history,
if
any
of
the
you
know
trusted
peer-to-peers
need
full
block
history
or
if
I
need
full
block
history.
C
D
All
in
all,
fairness,
in
my
opinion,
I
think
the
peer-to-peer
nodes
should
be
assumed
to
have
the
full
wall.
I'm
fine,
if
you're
Matthew
level
leaked
and
know
how
to
use
the
system
or
gray
math
and
write
your
own
five
layer
relay
system,
but
so
many
people
don't
realize
they
don't
have
they
don't
need
it,
but
they
don't
realize
nobody
can
sink
the
chain
anymore.
I
got
some
chain.
D
I
cannot
sync
the
chain
because
nobody's
everybody
use
Snapshot
and
didn't
realize
it,
and
now
there's
no
public
peer-to-peers
and
they're
like
oh,
my
peer-to-peer
is
working
not
for
the
first
on
a
million
blogs.
It
isn't
it.
So
that's
practice
in
my
opinion,
is
you
should
have
full
logs,
because
the
pier
is
going
to
possibly
try
to
ask
we're
blocked
IV.
You
should
have
oh
laws,
it's
just.
We
didn't
configure
it
on
this
note.
D
We
put
it
on
our
public
peer-to-peer
endpoints,
which
is
not
these
correct,
so
I
error
on
the
side
of
the
best
practice
for
Less
lead
than
Matthew
in
my
opinion,
would
be
to
remind
them
that
peer-to-peer
is
the
source
of
the
chain
history.
You
should
try
to
have
the
full
logs,
because
then
you
know
you
can
sync
the
chain
that
anybody
who
asks
it's
not
a
requirement.
You
know
I
mean.
Obviously
you
can
do.
What
you
want
to
do.
I
can
run
block
production
on
a
state
history,
news.
D
Maybe
that's
why
I
bought
jumble,
but
anyway,
that
makes
sense
that,
just
in
the
history
of
what
I've
seen
on
other
chains
and
people
that
don't
know
it
like,
we
know
it,
they
did
not
realize
that
they
were
jump,
starting
with
a
snapshot
and
the
service
they're
providing
was
only
half
of
the
peer-to-peer
service,
they
don't
have
the
they
don't
realize
that
they
don't
have
it.
They
thought
they
got
it.
You're.
D
Then,
but
then
it
is
a
misconception
from
a
lot
of
people
getting
into
it
that
they
just
didn't
realize
what
a
snapshot
is
just
the
state
database.
Yes,
you're
answering
peer-to-peer
requests
going
forward
and
what
you
have
in
your
log
from
this
point,
but
like
people,
will
line
up
six
different
peer-to-peer
connections
and
then
come
and
ask:
why
isn't
it
syncing
right
and
it's
because
I
had
not
questioned
like
five
times
in
the
past?
You
know
four
years
since
Germany
was
up.
Why
is
this
node,
not
sticky
Kevin's
like
do
you
have
the
blocks?
D
Oh
yeah,
oops
corrected!
That's
why
I
tend
to
say
is
that
when,
when
you
get
outside
of
you
know,
Elite
level,
note
operators
when
you
talk
about
best
practices-
and
it's
on
peer-to-peer
in
general,
you
know-
is
that
you
should
try
to
have
the
whole
block
log.
Unless
you
know
you're
you're
not
intentionally
doing
it,
because
you're
the
source
of
the
history
of
the
chain
and
a
lot
of
people
lost
that
had
a
lot
of
change.
That
kind
of
end
themselves
up
match.
If
I
can
get
it
back,
yeah
so
minutes
over
odd
purposes
blocks.
D
That's
the
only
purpose
for
them,
so
that's
why
we
didn't
put
any
history
on
it
and
I
shoot
myself
from
the
foot
every
time
I
try
to
get
more
than
24
hours
out
of
business,
damn
it's
not
sinking,
and
if
that's,
why
I
say
that's
practice
but
and
I
want
to
optimize
the
news.
I
don't
want
to
throw
more
gists
on
all
these
I'm,
not
saying
prevent
it.
Don't
rip
it
out,
I'm.
D
Just
saying
that
we
tend
to
do
things
that
now
have
percolated
to
the
next
generation
of
nothing,
bad
men
and
realizing
they're,
not
they're,
not
aware
of
what's
down
and
part
of
the
problem
is
the
terminology
is
not
consistent
across
the
blockchain.
So
if
you
come
from
say
polygon,
you
say:
oh
I
want
a
snapshot.
A
snapshot
means
in
polygon
terms.
All
the
blocks
right
right
in
in
alkalope
term
snapshot
means
just
the
current
state
right.
So
if
you're
coming
from
another
ecosystem,
the
terminology
is
not
aligning
because
I
got
confused
at
the
beginning.
D
It's
like
why
in
hell
are
people
talking
about
archive
nodes
and
full
nodes
and
I
don't
understand,
because
this
was
like
this
is
ethereum
terminology
and
then
people
coming
to
Apple
trying
to
find
the
same
thing
and
then
it's
confusing
now
I
know
ethereum
says
it's
like.
Oh
now,
I
understand
why
people
ask
these
questions.
C
D
D
Now
and
most
people
are
going
to
because
that's
Next
Level
there,
in
my
opinion,
launching
an
analog
note.
It
made
it
well,
this
isn't
yeah.
This
is
the
challenge
right,
so
you
need
a
fast
disk
if
you're
not
using
tempt
at
best
or
you're,
not
using
heat
mode
I'm,
trying
to
kill
those
two
95
of
the
people
that
I
work
with
that.
Aren't
you
Matthew
or
Stan,
or
even
get
the
concept
of
yeah
you
can't
even
you
have
to
launch
it
from
a
snapshot.
D
Every
time
you
reboot
it
I'm,
not
saying
that
you
can't
hot
rod.
It
I'm,
saying
criminal
General
aspect
is
that
now
most
people
are
they're,
throwing
them
on
hard
drives
and
not
understanding
why
it
isn't
working
well,
you
can
run
some
of
it
on
hard
drives,
but
State
could
be
on
a
hard
drive.
It
needs
to
be
on.
D
You
know
what
I
mean
and
they're
like
oh
I'm
up
online
I'm,
not
paying
SLA,
says
I'm,
perfect,
yeah
man,
you
ain't
on
an
Enterprise
fiber
circuit,
you
know,
or
what
I
even
found
through
history,
with
some
BPS
we're
having
latency
issues
and,
ultimately
from
what
they
reported
was
narrowed
down
to
their
disk,
which
was
probably
running
state
right,
getting
failed,
overloaded
and
causing
it
to
lag
in
itself.
So
that's
what
I
say
at
the
device
layer,
level
yeah
at
work
and
Trigger.
You
know
make
sure
you
have
a
good
internet
connection.
C
D
D
Needs
a
block
while
you're
right.
How
do
you?
How
do
you
restart
it?
If
you
have
zero,
you
always
use
a
snapshot
if
you're
retaining
order
keeps
the
state,
when
somebody
just
picks
back
up
and
builds
it,
so
our
BP
nodes
actually
run
in
without
temp
fs
and
without
keep
mode
they're.
Actually
you
know,
as
you're,
describing
writing
stuff
to
disk
all
the
time
and
killing
those
discs,
but
they
don't
have
to
write
any
blocks
right.
So
every
six
months
I
need
to
replace
the
disk
in
the
vpnet.
C
E
C
D
I
think
you
know,
looking
at
the
idea
of
4.0
is
speed
up
everything.
So
then
we
don't
need
these
nodes
at
all
right.
It's
kind
of
the
goal,
and
if
that
is
not
successful,
then
I
will
go
campaign
for
a
light.
Note
which
yes,
I,
need
all
the
state
or
even
the
re-architecture,
like
carving
off
the
Brads
I.
Think
Kevin
mentioned
some
of
that
block.
But
if,
if
four
dot
all
fixes
the
problem
that
we
don't
need
dedicated
block
relay
nodes,
then
we're
good.
We
don't
just
Constable
discussion,
we're
good,
well
I've.
C
C
D
Is
not
the
revised,
but
it
won't
okay.
What
my
my
in
my
head,
probably
the
best
idea,
is
whatever
the
hell
that
no
end
point
is
I,
don't
think
it
really
gets
used
for
much
other
than
providing
info
about
the
node.
If
get
info
were
under
that
node,
if
it
were
a
stable
loan,
I
think
it's
still
under
the
HTTP
plugin,
but
to
put
all
the
stuff
that
we
use
in
its
own
plugin
and
get
away
from
it
actually
being
push
request,
transactions
and
get
tables
and
all
the
rest
of
it
with
correct.
C
D
You
would
get
get
info
out
of
chain
API,
in
my
opinion,
that
probably
addresses
a
lot
of
that
yep
now
I
also
petition
for
a
git
info
2.
That
has
a
lot
of
that
Prometheus
data
in
a
rest,
Json
structure,
but
that's
a
different
conversation
but
I.
In
my
opinion,
it
all
boils
back
to
the
only
reason
you
keep
getting
that
chain
API
in
there
is
because
we
need
get
input,
disagree
damn
if
we
just
move
it.
D
And
some
of
the
duration
setting?
Okay,
that's
what
kind
of
prevents
somebody
else
from
shoving
it
down
your
throat
and
you
getting
transactions
to
then
have
to
slow
fall
because
you
want
to
be
a
block
only
relay
so
you
tell
everybody
I'm,
not
accepting
any
of
your
inbound
transactions
right.
Just
your
block!
That's
what
makes
it
block
only
for
dashboard.
D
And
just
in
case
you
want
to
control,
Blacklist
or
I,
don't
know
how
about
State
and
then
you
end
up.
You
can
run
snapshots
with
it.
You
can
control
the
The
Blacklist
whitelists
I,
don't
think
we've
ever
used
it
because,
like
the
blocks
only
knows
typically
just
the
net
API
is
the
bigger
one
for
you,
the
net
API,
for
sure
we
used
anything
here.
D
Yep
right
but
I'm
not
sure
if
the
producer
guys
list
and
block
listings
it's
going
to
be
on
a
node
that
has
transactions
once
they're
in
blocks.
What
do
you
need
to
control
it?
So
I
I,
agree:
100!
That's
why
I
was
like
I,
don't
know,
produce
your
API
I
mean
it's
not
forbidden.
Miss
Dennis
hasn't
conflict.
Let's
have
it
on
everywhere.
So
that's
all
correct.
That's
it
it's
one
of
the
ones!
That's
easy
to
have.
D
Not
the
biggest
thing
I
get
burned
out
of
why
I
tend
to
leave
it
on
is
because
I
do
work
on
the
Node
and
I
just
want
to
be
like
damn
it
I
just
want
to
take
a
quick
snapshot,
lasted
upgrade
it
do
whatever
and
I
keep
running
a
snapshot.
On
that
note,
I
got
a
code
of
my
Snapshot
repo
and
go
find
one
from
an
hour
ago.
That
auto-generated
you
know.
So
really
it's
just
you
know
from
an
Administration
side,
because
the
snapshot
action
is
buried
under
the
producer.
B
D
Time
I
need
one
I
just
run
the
command.
It
stops.
Node
us
blows
away
all
the
data
directly
downloads.
The
snapshot
sticks
it
there
and
starts
nodes,
so
yeah,
but
like
for
instance,
I
mean
like
with
my
wax
snapshots.
It
takes
30
minutes
for
that
whole
process
to
run
so
I'm
already
30
minutes
out
of
time.
D
I've
then
gotta
extract
it
back
out
and
deal
with
all
of
that,
whereas
I
found
him
if
I
could
just
run
a
quick
snapshot,
I'm
in
the
machine's,
bathroom
and
I
spit
it
out
in
10
10
minutes,
and
it's
current
I
don't
have
to
spend
the
next
hour
trying
to
catch
back
up
to
the
chain,
because
guess
what
my
load
balancers
are
responding:
stale
requests,
while
it's
trying
to
catch
up
this
30
40.,
while
your
load
balancer,
should
prevent
requests
going
to
that
node.
While
it's
in
the
process
of
syncing
I,
don't
disagree.