►
Description
Join us for this week's EOS Node Operator Roundtable as we discuss the latest developments in Antelope software and dive into the technicalities of Leap 5.0 configuration format proposals. Stay in the loop and don't miss these exciting updates! #EOS #NodeOperator #Antelope #Leap5 #Blockchain
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
Hello,
everybody,
it's
April,
12th,
we're
back
for
another
node
operator,
Round
Table
new
topic
again
today
we're
going
to
be
we're
going
to
be
dipping
into
5.0,
so
I'll
add
it
over
to
to
Brian
to
tee
that
up.
Unless
before
we
get
into
that
enough,
we
have
any
4.0
or
other
software
update.
We
usually.
C
Sure
so
yesterday
evening
we
did
release
rc3,
you
can
access
it
right.
There,
I
I,
think
that
probably
the
most
notable
bits
are
that
we
did
tackle
a
number
of
bugs
that
you
can
read
inside
of
the
release,
notes,
there's
a
number
of
tweaks
also
around
the
new
feature,
read-only
transactions,
and
then
one
thing
that
we
took
a
step
back
on
was
we're
actually
reintroducing
the
speculative
read
mode,
so
we're
still
removing
the
persistent
transactions,
but
we
are
reintroducing
speculative
mode.
C
C
On
the
heels
of
that
mentioned
a
few
times
that
we
will
be
releasing
cdt's
rc1
pretty
shortly
after
this
release
that
we
were
trying
to
get
out
so
I
anticipate,
probably
early
next
week.
At
this
point,
I
know
it's
kind
of
dragged
out
a
couple
of
other
weeks,
but
on
that
note
we
do
plan
to
demo
some
bits
of
that
this
coming
Thursday,
so
the
one
after
the
one,
that's
tomorrow,
that
is
inside
of
a
new
meeting
that
we've
stood
up,
that
is
a
developer
office
hours.
C
It's
kind
of
the
sister
meeting
for
this,
in
effect
for
Antelope
developers,
maybe
a
slight
EOS
lien
there,
just
since
it's
being
driven
by
the
enf,
but
we
got
some
good
feedback
there.
Just
this
last
installation,
which
was
last
Thursday
and
looking
to
get
that
up
and
running
so
really
excited
about
that.
C
And
if
you
have
anyone
on
your
team
that
may
be
interested
in
attending
something
like
that
feel
free
to
drop
me
a
line
I'll
be
helping
lead
that
meeting
with
Nathan
and
Bucky
from
our
team,
so
I
think
that's
about
it
from
our
end,
I
guess
the
only
other
thing
that
will
well
no
I
think
that's
it
actually.
Sorry.
C
C
Focus
demo
here
I
think
that
that's
kind
of
like
the
Rhythm
that
we'll
have
here,
but
we're
hoping
to
actually
do
that
more
frequently,
not
just
like
when
the
release
is
like
dropped
at
like
the
front
door,
but
actually,
when
we're
actually
delivering
those
features,
not
materially
to
a
production
environment
in
any
way.
But
whenever
we've
actually
gotten
a
feature
complete
and
similarly
we're
leading
in
with
the
developer,
tooling,
primarily
leading
in
from
CDT
in
Dune.
C
The
biggest
thing
that
I
think
we'll
be
talking
about
is
part
of
this
broader
system
that
we're
building
out
called
antler.
The
first
bit
is
antler
project,
which
is
just
like
a
project
and
package
management
system
that
should
really
ease
just
setting
up
your
project.
So
that's
what
we'll
be
cruising
through
and
again.
That
will
be
this
next
Thursday
a
week
from
tomorrow
at
9.
00
a.m,
Eastern
just
to
keep
it
at
same
time,
but
just
a
day
later
than
this
meeting
and
it'll
start
off
every
two
weeks.
C
C
A
B
So
I
think
the
you
know
the
demo
last
week
kind
of
we
didn't.
We
didn't
have
I'm
to
sort
of
take
questions
and
get
feedback
in
that,
and
so
the
what
I
want
to
do.
Moving
forward
is
just
like
what
Stephen
said
for
the
developer
for
the
developer
meeting,
which
is
we're
gonna.
Do
demos
sort
of
incrementally,
as
things
are
Dev
done,
so
that
we
can
get
feedback
on
things
with
enough
time
to
potentially
change
them
if
something's
wrong,
but
even
to
avoid
that
problem.
B
C
A
B
B
B
Ip
addresses
host
names
and
ports
for
different
categories
of
those
HTTP
endpoints
and
be
able
to
do
like
secure
and
efficient
local.
Only
connections
with
with
Unix
socket
paths.
That's
why
that's
included
as
far
as
like
the
categories
we're
proposing,
which
maybe
I
should
actually
flash
my
screen
up
so
that
people
have
something
they
can
look
at
and
don't
have
to
try
to
Commit
This
to
Memory
just
a
moment.
A
C
F
E
F
So
currently,
and
and
4.0
latest
RC
there
is,
you
can
put
Prometheus
on
its
own
port,
so
there's
a
separate
configuration
for
Prometheus.
Everything
else
is
on
the
HTTP
server
address,
that's
configured,
and
so
that
includes
whatever
you
enable
so
which
of
the
whichever
one
of
the
apis
chain
API
or
producer
API
or
net
API.
F
All
those
would
be
on
the
same
board.
So
what
this
is
is
suggesting
proposing
is
that
we
set
up
categories
and
these
categories
would
be
pretty
much
aligned
with
the
the
plugins.
Although
a
few
of
the
plugins
we
split
kind
of
in
two
and
the
read-only
and
read
write
with
the
idea
that
we
we
should,
it
would
be
useful
to
split
that
functionality
between
those
two.
So
it
doesn't
go
all
the
way
of
saying
hey.
F
Let's
allow
you
to
configure
a
unique
address
import
for
every
single
endpoint,
which
would
have
been
the
pitch
like
the
the
draft
apply
I
mean
we
could
do
that.
It's
just
like
that
seems
a
bit
Overkill.
So
instead
and
then
we
thought
well,
the
other
idea
is
we
can
do
it
by
plug-in
what
we
know
like
that.
Everybody
wants
to
get
control
on
its
own
order.
F
Separate
I
mean
we've
heard
that
a
number
of
times,
and
so
it's
like
okay,
that
one
would
want
to
maybe
well
like
we
could
have
done
that
by
pulling
that
into
its
own
plug-in,
for
example,
but
then
at
five
well,
what
this
proposes
just
this
General
concept
of
categories,
and
then
we
can
put
various
endpoints
and
new
categories
and
allow
you
to
configure
the
categories,
and
then
we
could,
you
know,
get
feedback
on
what
should
be
in
each
of
these
categories
or
add
new
categories.
Kenny.
E
F
So
the
default
would
be
fall
back
to
yeah
on
the
same
portal:
yeah
yeah,
okay,
you
can
yeah,
you
can
change
individual
categories
like
if
all
you're
in
is
is
moving
get
info
on
its
report.
You
can
leave
everything
else
alone
and
just
take
get
info
and
put
it
on
it.
Put
a
quick
hit
in
its
own
category
until
we.
E
F
Right
so
you'd
be
able
to
configure
it
either
for
a
a
Unix
path,
socket
configuration
which
we
support
or
ipv4
or
ipt
six
now
IPv6
support
is
also
will
be
added
as
part
of
our
work
for
Vital,
at
least
that's
the
current
plan.
It's
the
ad
is
worth
for
ipg6,
which
we
currently
do
not
have.
That
would
be
part
of
this
world
as
well.
D
E
Yeah
from
our
perspective,
this
is
like
a
nice
to
have
wouldn't
have
been
something
on
my
high
priority,
but
IPv6
that
that
is
a
priority.
Foreign,
the
threads
and
whatnot
behind
the
scenes
are
still
the
same
though
correct.
This
is
almost
like
a
proxy
kind
of
in
front
if
it's
a
heavy,
if
like
get
info,
it's
pretty
heavy
I
think
right.
So
that's
still
rolled
into
the
normal
threading
with
all
of
the
other
endpoints.
E
F
All
the
existing
HTTP
configuration
options
would
apply
across
all
these
addresses,
so
there's
like
Max
body
size
or
number
of
requests
in
Flight.
You
know
there's
a
number
of
and
like
certificate
sort
of
things,
all
that
would
be
across
all
the
endpoints
of
that
or
continue
we're,
not
we're
not
specifying
as
part
of
this
unless
we
get
different
feedback
here.
B
F
Yes,
so
you'll
see
like
why,
94.95
that
that
the
chain
read
only
is
specified
for
two
different
addresses.
Now
you
know
again,
those
are
both
just
local
hosts,
but
that's
the
that's
to
illustrate
the
fact
that
you
can
actually
list
a
category
as
many
times
as
you
want
and
it
would
listen
on
all
the
various
or
or
in
points,
and
so
one
could
be
ipv4
one
could
be
iqv6,
Etc
or
like
on
line
93.
You
can
configure
it
to
just
listen
to
to
all
of
them
right.
D
F
Right,
well,
you
can
lift
it
twice
for
sure
you
know
like
you
could
do
just
you
know.
Just
like
94.95
lists
read
only
twice.
You
could
have
two
entries
one
for
ipv,
four,
one,
five,
six
I'm,
not
sure
we
could
certainly
come
up
with
a
syntax.
That
would
that
would
do
that
as
well
just
say:
listen
on
ITV
we're
in
ipt
six
on.
E
F
F
B
E
So
that's
superb
I.
Think
from
my
perspective,
I
just
find
it
not
that
important,
because
typically
you'd
have
that
hosted
by
heart
anything
public.
It's
going
to
be
a
heart
behind
a
load
balance.
Anyway,
we
put
it
behind
a
load
balancer
because
we
have
to
we'll
end
up
those
types
of
things,
but
so
awesome
all
right.
E
Sorry,
Michael
I'm,
not
trying
to
talk
about
you.
You
probably
thought,
but
the
reason
I
came
up
with
it
is
that
you
can
go
to
any
note.
That's
running
the
snapshot
which
we
do
all
the
time.
It's
a
pain
to
now
be
able
to
run
local
snapshots,
but
you
can't
leave
it
on,
because
if
somebody
knows
that
you
have
that
on
and
you're
not
blocking
it,
they
can
freeze
the
node
so
being
able
to
carve
off
or
pause
a
producer,
or
any
of
that
I
mean
the
get
info
and
all
the
other
ones.
E
Yeah,
that's
great
I
mean
whatever,
but
really
the
big
one
that
we
brought
to
light
was
that
damn
producer
API
and
how
you
can
jack
up
your
producer
or
even
freeze
it
with
snapshots
pretty
easily
just
because
you
can't
put
it
you
can't
even
separate
it.
You
never
want
public,
API
or
just
to
have
that
type.
Look
I'm,
sure,
I'm,
sure
that
this
is
being
covered
at
knows
them
already,
but
you
know
there's
a
way
to
on
your
load
balance.
It's
only
Ford
specific
requests
more
than
just
a
port
and
there's
also
certain
plugins.
E
B
Right
and
to
to
to
Michael's
point
just
to
make
sure
you
know
it's
clear
is
like
the
the
approach
here
is.
We
saw
that
there
were
specific
things
where
this
would
be
valuable.
Like
Prometheus
exporter
was
the
first
example
of
it,
but
also
get
info
has
come
up,
but
you
know,
as
Michael's
and
laughing
said
over
and
over
again
is
like
a
thing
that
you
might
want
to
separate
off
so
rather
than
trying
to
go
sort
of
piecemeal
with.
B
F
Just
if
you
could
look
at
the
categories
here,
if
anybody
has
any
like
immediate,
like
oh
that
doesn't
make
sense
for
I-
would
want
this.
So
these
are
the
categories
we're
proposing
so
get
info
on.
It's
all
a
chain
read
only
basically
just
all
the
git
operations
and
then
on
the
Chain
art
RW
would
be
all
the
all
the
abilities
to
you
know:
push
a
transaction
or
compute
transaction.
Now
we
do
have
send
read
only
transaction
in
the
art,
our
zero
category,
so
make
note
of
that.
F
So
you
know
those
are
ones
to
think
about.
We
did
split
up
the
net
as
well.
The
light
I'm,
not
sure
that
that
would
actually
be
useful,
whether
it
would
really
ever
that's
right.
Net
read
only
separately,
the
net
red
W
seems
like
that,
would
probably
all
wouldn't
be
restricted
and
the
same
thing
with
the
producer.
We
split
that
up
between
we
go
away
and
read,
write
as
well
again,
I'm,
not
sure
whether
that
would
ever
be
useful.
F
You
know
I
I,
don't
know
so,
maybe
though
it
doesn't
make
sense
to
have
different
categories
for
producer
or
net,
but
certainly
putting
snapshot
over
on
its
own
well
in
its
own
category.
I
think
makes
sense
and
also
note
that
we're
not
changing
any
of
the
endpoint
names.
So
it's
still,
it
would
still
be
B1
producer,
even
though
it's
for
snapshot
functionality
just
because
just
to
keep
that
backwards.
Compatibility.
E
And
that
was
a
big
one,
too
Ross.
Whenever
we
were
talking
about
it
being
able
to
manage
your
peers,
you
can't
expose
that
because
it
kind
of
got
routed
into
the
normal
ACP
and
then
you
had
to
kill
it
at
the
proxy
level,
so
it
just
allowed
node
OS
to
do
it.
So
that
would
be
another
big
one.
In
those
conversations
cool,
yes,
read.
A
F
E
F
That's
a
really
good
question
and
and
I
could
definitely
see
it
being
pushed
in
the
other
category
that
the
main
reason
I
thought
of
putting
it
here
currently
is
that
all
the
ones
above
it
all
those
are
capable
of
running
in
in
a
new
in
the
4.0.
One
of
the
new
features
you
get
is
the
ability
to
just
specify
a
read
window
and
a
right
window
configuration
with
a
read-only
thread
pool
and
then
and
that
during
the
read
window,
all
the
operations
that
are
that
are
in
the
chain.
F
Ro
category
are
able
to
run
in
parallel
in
the
in
that
thread
pool.
So
that's
not
true
of
compute
transactions.
So,
even
though
compute
transaction
from
a
user's
perspective
does
not
modify
anything
as
an
implementation
detail,
it
actually
does
it
actually
modifies
things
in
the
database
and
then
rolls
back
those
changes.
F
So
it's
not
possible
currently
to
run
compute
transaction
in
parallel
on
a
node,
it
is
possible
to
to
execute
the
read-only
transactions
in
parallel
on
a
node,
and
so
that's
why
those
two
categories
so
that
the
idea,
my
idea
of
like
separating
these
two
categories,
is
as
a
node
operator.
What
what
you
could
do
with
4.0
would
be
kind
of
exciting.
To
do.
I
think
is
that
you
could
have
two
API
nodes,
one
that
sets
up
the
chain
and
read
read
write.
Of
course
you
could
do
this
today
with
4.0.
F
That's
the
max
we're
allowing
right
now,
there's
details
why
that's
currently
only
allowed
up
to
eight,
so
you
could
create
that
up
to
eight
and
set
the
read
window
to
say
whatever
500
milliseconds
in
the
right
window.
You
can
set
the
one
millisecond
on
that
note
because
it
doesn't
really
matter
when
you
set
the
right
window
to
as
soon
as
a
block
comes
in
it
actually
interrupted.
F
What's
it
what
it's
doing
applied
to
block
and
then
switches
back,
so
you
could
set
the
read
window
to
basically
the
entire
time,
the
right
window
to
basically
nothing
one
and
then
it
would
set
there
for
the
entire
time
running
on
the
lay
thread
in
parallel
processing.
All
of
these
read-only
calls,
so
you
can
separate
out
your
your
your
infrastructure
in
that
way.
Get
you
know.
Potentially
you
know
much
higher
throughput.
E
E
B
F
Yeah
I've,
given
a
rationale
why,
in
these
categories
now,
I
could
certainly
see
from
a
a
logical
perspective
that
you
might
want
compute
transaction
up
in
the
other
category,
I
mean
I
can
see
that
making
sense
I'm
doing
it
I
did
it
more
from
a
practicality
standpoint
in
terms
of
like
the
configuration
I
just
I
just
suggested,
but
I
could
certainly
see
it
being
or
maybe
even
like,
maybe
it
that
should
be
a
separate
category
altogether.
Maybe
it
should
be.
You
know,
chain
compute
or
whatever
you
know.
We
that's
the
kind
of
feedback.
F
If
we
could
I
don't
know
if
you
shared
a
link
to
this,
if
some,
if
you
guys,
could
take
a
look
at
these
categories
and
think
through
like
yes,
this
makes
sense
or
no
this
should
be
in
this
other
category,
or
this
is
important
enough.
That
I
would
want
it
in
its
own
category
or
that's
the
type
of
feedback.
I.
Think.
C
Yeah
and
just
hopping
in
right,
quick
from
a
process
perspective
I
think
it's
a
goal
of
ours,
as
these
proposals
come
together.
Moving
forward
that
it
would
be
great
to
have
people
comment
directly
on
these
PRS
that
are
submitted.
That's
kind
of
the
process
as
it
is
or
had
started
off
is
inside
of
the
product.
C
B
A
A
E
Well,
maybe
maybe
not
I'm
wondering
okay,
so,
like
we've
got
the
nobody
who
has
to
monitoring
thing
that
you
know,
one
of
the
teams
here
is
working
on,
which
is
great.
So
maybe
you
want
people
to
be
able
to
look
at
the
status
of
something
but
not
be
able
to
control
it
so
looking
at
who's
connected,
but
not
enable
the
the
actual
making
connection
changes
so
I
think
that's
a
separated.
E
Okay,
request
for
the
monitoring
you
might
want
to
have
the
monitoring
enables
publicly-
or
at
least
to
you
know
like
an
IP
on
your
land,
for
example.
So
anybody
can
access
it
when
they're,
you
know
grafana
or
whatever
they're
using
and
then
have
the
connect,
like
you
said,
specified
only
to
localhost
store.
Let
me
see
where
the
noodle
Creator
only
can
access
it.
Yeah,
that's
how
we
have
it
right.
E
So
if
there's
three
levels
of
access
in
our
Network
there's
the
public
stuff,
that's
enabled
through
the
low
public
load,
balancer
there's
if
you're
on
the
internal
Lan
access
and
then,
if
your
SSH
into
the
machine
itself
accessed
right.
So
we
could.
You
know
the
the
public
things
that's
at
the
top
of
the
list
is
off
the
screen.
That's
gonna
we're
gonna
make
that
available
everywhere.
Then
the
net
read
only
we
might
Avail
make
that
available
to
a
certain
IP
addresses,
that's
used
for
monitoring
and
then
the
read
write.
E
Well,
you
have
to
access
this
agent
machine
to
make
big
case,
because
then
we
have
the
permission,
because
none
of
these
apis
have
a
permission
level
with
a
password
or
whatever
right,
they're
just
open
or
not.
So
you
need
to
be
able
to
restrict
who's
allowed
to
make
changes,
and
you
can
do
that
by
who's
allowed
to
SSH
into
that
machine.
Mm-Hmm
right.
So
we
have
to
think
about
organizations
that
have,
like
you
know,
say:
a
hundred
employees
and
different
employees
have
different
levels
of
access
and
not
just
well.
E
B
B
Yep
and
another
little
justification,
this
one's,
maybe
a
little
bit
weaker,
but
like
configuration
like
this
is
probably
kind
of
a
more
of
a
one
and
done
type
of
thing,
and
so
the
extra
flexibility
comes
at
very
minimal
extra
complexity
for
node
operators
who
could
be
using
this
config,
so,
okay,
I
think
we've
probably
covered
enough
on
this
anything
else.
We
should
go
into
on
this
before
I
move
on.
E
See
the
chat
I
get
supported.
Api
is
right,
so
we
have
an
endpoint
that
allows
you
to
see
which
apis
are
supported,
but
now
what
now
these
apis
are?
Maybe
internal
external
whatever.
So
in
our
implementation,
we
actually
filter
the
get
supported
apis
based
on
what
we've
allowed
through
the
firewall
or
the
load
bouncer
right.
So
we
don't.
We
take
get
supported
apis,
remove
everything.
It's
not
V1
chain
and
then
publish
that
list
is
what's
available,
which
is
you
know
a
bit
manual
to
do.
F
Yeah,
that
makes
sense
his
proposal
doesn't
mention
that
at
all,
and
actually
just
put
says,
put
it
on
a
separate
Port
but
yeah
I,
agree.
I,
think
it
makes
sense
for
it
to
be
supported
on
each
configured
port.
To
tell
you
what's
on
that,
Port
I
mean
that
seems
like
what
it
should
do
and,
of
course,.
B
F
Rat
so
as
this
sort
of
proposal
is
written,
it
remains
and
it
just
returns
like
everything
I
mean
the
other
option
which
I
don't
think
we'd
want.
Is
that,
like
you,
could
keep
it
on
its
own
port
and
it
would
return
all
the
information
so
what
courts
are
on,
but
that
seemed
like
an
anti-feature.
Wouldn't
what
ministers
be
able
to
see
that
information
like
so
I
I?
F
It
seems
like
what
it
ought
to
do
with
what
Matthew
just
described,
because
kind
of
what
they're
doing
manually
is
that
it
should
just
according
to
whichever
of
the
configured
endpoints
you
hit.
It
tells
you
all
if
it
pretends,
like
that's
the
only
input
there
is.
It
tells
you
on
that
endpoint.
What's
available.
E
Is
it
configurable,
or
is
it
still
just
only
going
to
look
at
what's
bound
to
it,
because
what
we
run
into
is
the
no
is
going
to
respond,
but
it's
not
always
aware
of
all
the
features
that
it
actually
shouldn't
respond
with.
So
you
end
up
going
in
there
and
saying
no
I
do
offer
history
just
not
on
this
and
that
because
that's
the
one
you're
gonna
call
to
you
know
what
a
lot
of
us
did.
Is
we
put
a
static,
Json
and
said:
no,
you
don't
even
ask
a
node
anymore.
E
A
E
E
E
Left
it
or
mutated
yeah
send
it
back
based
on
here's
the
list
that's
available,
plus
I
added
V1
history
to
the
list.
I've
requested
it
from
bad
side
as
well,
don't
think
that
that
hasn't
been
but
yeah
yeah.
That
was
always
an
issue,
but
it
also
whenever
you,
you
have
multiple
modes,
providing
different
things.
If
they
answer
from
this
one,
it's
not
going
to
know
that
actually,
maybe
I
do
all
for
mine
peer
status,
information.
E
D
Right,
I
think
what
this
will.
Let
us
do
is
right
now,
all
of
us
if
we
modify
the
response,
we're
removing
things
like
we
we're
like.
Oh,
it's
reporting
that,
but
we
block
it,
so
we
remove
it.
But
what
this
will
do
is
let
us
like.
Let's
say
we
had
three
upstreams
in
our
load:
balancer,
whether
it's
different
machines
or
whether
it's
different
ports
here,
instead
of
removing
things
and
then
hosting
it
statically.
What
we
can
do
in
the
load,
balancer
is
just
combine
that
Json,
like
our
three
upstreams,
have
different
capabilities.
D
But,
okay,
let's
just
call
all
three
upstreams
combine
that
Json
and
then
cache
it
there's
no
more
static
in
removing.
It
would
be
a
process
of
just
merging
everything
that
we
do
offer
out
of
that
unless
you
are
going
granular
enough
as
to
where
you're
blocking
something
out
of
one
of
those
categories,
but
I
think
everything
that
I've
removed
is
now
broken
into
those
categories
so
I
wouldn't
have
to
remove.
Maybe
somebody
else
has
an
example
of
something
they
still
would
remove
out
of
one
of
those
categories.
D
E
E
F
B
E
Think
it
could
be,
but
I
don't
know
it
could
be
added.
So
read
online
yeah.
Maybe
it's
like
an
admin,
the
second
it's
an
internal
admin
thing,
it's
not
being
there.
We
need
to
see
what
was
it
because
I,
don't
ever
I
wasn't
involved
with
that
problem
that
trigger
don't
run
this
publicly,
because
it'll
get
abused
or
can
cause
a
problem.
I
know
it's
always
a
security.
You
don't
export
it.
If
you
don't
need
to
that's
the
only
reason.
Yeah,
okay,.
A
E
Yeah
more
just
the
the
data,
not
it
doesn't
add
like
a
so
they
could
freeze
you
node
for
no
hey,
so
disconnect
all
your
peers
types
of
things.
Okay,
it's
more
from
a
this
node.
Has
this
much
RAM
allocated
to
it.
So
if
I
just
increase
the
chain
X,
then
I
can
cross
your
node,
because
I
know
how
big
it
is
right.
E
E
E
E
Maybe
forget
it:
oh
what
I
would
say
it
was
we're,
starting
to
expose
other
doors
for
us
to
get
this
type
of
admin.
Information
out.
Maybe
I'll
call
it
again
in
part.
Two
we've
got
the
Prometheus
exporter.
She
could
parse
it
if
you
wanted
it
yeah.
The
other
way
before
was
to
use
HTTP
in.
So
that's
why
all
these
existed,
and
then
it
was
like.
E
E
So
Michael
I
actually
like
your
comment
here,
because
I
think
if
we
have
get
info
2
or
what
I'm
calling
it
get
server
info,
which
is
the
get
info
plus
extra
stuff,
that's
meant
for
the
node
operator,
not
for
the
user,
then
putting
DB
size
into
get
server
info
would
be
perfectly
reasonable.
It
sounds
reasonable
to
me,
yeah
I.
Get
server
info
is
the
one
that
you
want
to
separate
at
the
beginning
of
Brian's
list
yet
get
info
on
a
separate.
E
Really
you
want
that
as
get
server
info,
which
is
the
internal
one
and
get
info,
is
the
one
that's
available
publicly
I
shot
about
that
because,
like
I,
say
I,
we
want
to
kind
of
separate
some
of
that,
but
get
info
is
heavily
used
or
dramatically
to
figure
out
all
right.
Here's,
the
Baseline
yeah
this,
the
the
public
get
info
should
be
with
the
chain.
Read-Only
stuff
and
get
server
info
should
be
a
separate
one
for
server
for
node
operators
on
a
sub
report,
which
has
the
DB
size
included.
E
E
But
that
is
a
valid
point
that
I
my
thought
was
when
I
saw
that
first,
one
on
the
list,
I
was
like
I'd
love
to
carve
off
get
in
because
I
think
it's
a
heavy
call
too
right,
I
mean,
and
they
just
is
it
just
can't
I
think
in
relation
to
some
of
the
other
things.
I
don't
know,
I
could
cause
it.
No,
maybe
it's
not,
maybe
maybe
I
don't
know
we
can't.
E
We
can't
get
info
for
one
second
I
think
I
thought
I,
remember,
say,
because
that
we
aggressively
monitor
it,
because
that's
our
only
way
to
monitor
a
server
and
it's
like
when
it
really
comes
down
to
it.
It
flows
in
a
super
cheap
call,
but
maybe,
if
not
I,
just
whatever,
but
the
point
was
we
were
never
going
to
be
able
to
remove
that
from
our
public
apis.
But
that's
not
the
good
info
that
really
needs
to
be
isolated
in
that
type
of
load.
E
It's
a
better
one,
get
server
info
or
maybe
get
server
info
as
parameters,
or
maybe
it's
multiple
calls,
depending
on
whether
you
want
the
node
OS
config
ini
versus
the
DB
size
versus
an
app
where
we
would
report
DB
size.
That's
where
the
boards
free
space
that
you
wanted
to
be
able
to
provide
some
of
those
other
metric
a
lot
of
the
examples
from
Prometheus,
because
those
are
the
things
we
want.
E
I'm
sure
you
have
but
there's
another
little
special
thing.
All
of
these
cool
queries
make
sure
they
happen
on
a
different
thread
to
to
notice
like
the
nodius
like
apis
and
block
production.
Okay.
Well,
that's
what
I
was
saying.
Is
it
it
didn't
get
info
off
on
a
different
thread.
I
thought
was
a
concern
because
it
got
hammered
and
was
heavier
replied.
I
mean
era
deals
with
more
get
infos
than
probably
any
other
man
on
this
Earth
and
Matthew.
Probably
second
well.
I
trust
his
opinion.
Yeah.
D
E
Well,
it
and
a
more
advanced
getting
like
that
exactly
what's
in
get
info
because
of
what
it
is
is
just
a
limited
amount,
but
there's
a
much
you
could
expose
like
we
do
with
our
big
mountain
earliest
block
available.
Yes,
in
your
Upstream
logic,
be
able
to
say
oh
nope,
that
one
doesn't
have
it.
I
need
to
go
to
this
one.
It
does
whatever
type
of
thing.
B
Yeah,
so
just
to
make
sure
I
are
synthesized
correctly.
Here
it
sounds
like
there's
a
desire
to
like
collapse,
some
of
the
existing
information
into
one
call
with
what's
provided
and
get
info
and
maybe
add
some
additional
information,
and
that
would
be
something
that
you
would
want
on
its
own
separate
category,
however,
get
info
itself
like
as
it
stands
today
is
something
that
you
would
pretty
much
always
make
public
and
therefore
could
be
added
to
the
like
producer,
read-only
or
sorry,
not
producer
read
only.
A
D
F
E
F
But
we'll
add
that,
as
I
think
is
its
own
category,
at
least
as
a
as
a
first
idea
here
and
then
what
I.
The
other
thing
I
heard
I
think
is
that
like
gen
info
should
be
in
two
categories:
it
should
be
in
its
own
category
and
it
should
also
just
be
included
in
in
chain
rebelling
right.
You
might
hear
that
if
you
were
enabling
chain
we'd
all
like
everything
else
in
there,
you
want
you
don't
know
what
get
info
as
well.
E
F
D
E
E
Damn
it's
nice
when
you
can
just
say
and
I
just
say:
I
see,
yeah
the
since
we're
here
and
talking
about
apis
I
know.
One
Stan
has
asked
for
a
long
time
ago
was
you
know
returning
200,
okay
versus
non-200,
okay,
if
the
the
chain
is
in
sync
or
something
like
that,
so
that
makes
it
very
easy
for
a
load
balancer
without
doing
any
programming
to
know
whether
to
include
that
node
in
a
in
the
the
loads
pool,
correct,
most
load,
balancers
check,
simple!
Is
it
there?
Is
it
not?
It
responds
with
the
200.
E
It's
just
got
out
of
date,
information.
The
note
knows
it's
behind
it's
in
scramble
sync
mode.
What
it's
still
saying:
oh
yeah,
here's!
We
see
it
a
lot
when
we
Theory
a
producer
schedule
and
Somebody's
gotta
replay
it
no
in
the
mix.
All
of
a
sudden.
It
thinks
the
Scandal
was
from
a
year
ago,
because
an
API
served
out
a
table
state
from
a
year
ago,
because
it's
catching
up
from
a
recovery
snapshot.
Something
like
that.
But
yes,
the
fact
that.
E
It
is
ready
or
something
V1
chain
is
ready,
correct,
correct
some
way
of
it.
Knowing
hey
I'm
responding-
and
you
can
even
query
me
because
I
know
we
write
scripts
to
keep
watching
it
to
see
where
it's
synced
right,
I
mean
I'm,
not
watching
Miguel,
Vlogs
or
anything,
but
knowing
if
I
turn
that
HTTP
on
it
don't
put
it
on
another
Port.
My
load
balances
are
about
to
start
routing
and
people
are
going
to
go
nuts
because
they're
getting
old
data,
and
you
think
it's
about
unless
you're
no.
E
Yeah,
it
is
a
healthy
way,
correct
and
I
I,
so
it
knows
a
difference
between
I'm,
really
behind
and
I'm
kind
of
behind,
because
there
is
this,
you
know,
I
mean
those
nodes,
can
kind
of
lie
behind
and
get
out
of
sync,
and
you
don't
want
to
just
shut
them
down
because
it's
two
seconds
behind
but
yeah,
but
my
thought
had
always
been
why
the
hell
does
it.
It
doesn't.
Do
it,
it's
a
threshold,
catch-up
model,
yeah,
no
I'm,
just
saying
this.
Health
endpoint
needs
a
configurable
threshold
to
say
what
it
is
right.
E
I
never
realized
there
was
still
there.
There
was
trigger
that
I
just
knew
it
fault
shifted
over
all
right
anyway.
So
yes,
configuration
option,
it's
some
threshold
to
say
give
me
the
ability
to
just
simply
know
do
I
route
requests
or
not,
and
so
the
reason
I'm
bringing
it
all
is
because
we're
talking
about
these
HTTP
endpoints,
which
might
be
available
on
all
the
ports
right-
and
this
might
be
one
of
them
or
maybe
not
I,
don't
know.
B
All
right:
well,
we
are
at
times
so
we've
kind
of
gone
into
the.
What
the
next
topic
would
have
would
have
been.
So
that's
good,
but
I
want
to
kind
of
give
some
homework.
There
will
be
a
pop
quiz
on
the
next
meeting,
just
kidding,
but
basically
I
do
want
to,
as
as
we're
sort
of
at
the
start
of
release,
planning
for
5.0
I
want
to
seek.
B
You
know:
feedback
from
the
community
and
node
operators
as
a
particular
part
of
that
around
what
you
know
what
your
dreams
are
for
5.0.
So
things
to
think
about,
of
course,
are
you
know
just
sort
of
the
stuff
that
are
constantly
causing
me
pain?
Also,
think
about,
like
you
know,
how
might
we
reinforce
the
things
that
make
Antelope
special
right,
you
know:
are
there
features
that
would
help
us
scale
more
perform
better,
have
better
interoperability
with
other
blockchain
things
provide.
B
You
know
meaningful
new
capabilities,
Drive
adoption,
Drive
utilization,
you
know
carve
out
more
of
a
unique
sort
of
niche
in
the
overall
blockchain
ecosystem.
All
these
sort
of
big
Grand
things
I'm
I'm,
inviting
you
to
to
think
about
those
and
I'd
like
to
discuss
this
next
time,
just
to
collect
some
of
those
thoughts,
so
that
they're,
not
just
in
your
head
and
potentially
could
feed
into
things
to
include
at
5.0
or
a
later
release
prior
resource.