►
From YouTube: Node Operator Roundtable - January 17th, 2023
Description
This week, the EOS Node Operator Roundtable updates the community on Antelope software development and has a technical discussion on Antelope resource models.
00:00:00 Start
00:00:02 Antelope software development update
00:11:04 Antelope resource model technical discussion
00:18:08 Resource model update
00:26:18 Topics for future calls
00:41:55 Read-only node EOS instances
00:54:22 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
Welcome
everybody:
it
is
January
the
18th.
This
is
week
15
since
EOS
Independence
we're
continuing
the
discussion
on
Antelope
resource
model.
O'brien
is
going
to
leave
that
before
I
hand
it
over
to
Brian.
While
we
can
get
an
update
from
Stephen
on
how
things
are
going
with
Antelope
software
development
side
of
things.
B
Yeah
absolutely
so
primary
updates
worth
mentioning
today.
Are
that
likely,
before
the
end
of
this
week,
or
perhaps
sometime
early
next
week,
we
will
be
performing
a
patch
release
against
3.1
and
3.2
I
think
that'll
be
3.1.3
off
the
top
of
my
head.
I'll
have
to
click
back
in
since
it's
been
a
while
and
then
of
course,
3.2.1
primary
thing
here
is
that
there
are
just
some
ship
instability
issues
kudos
to
Kevin
for
knocking
that
out,
while
Brian
and
I
were
off
site
this
last
week.
B
Thank
you
for
that,
and
then
other
big
update
is
that
we
do
anticipate.
Probably
a
new
release
of
of
Dune
I
would
anticipate
probably
early
next
week
and
I
think
that
one
will
be
v1.1
big
take
home.
There
is
just
it
will
be
better
at
managing
different
versions
of
the
other
pieces
of
software
that
it's
dependent
upon.
B
So
so,
instead
of
being
hard-coded
values
for
the
most
recent
release
versions
of
things
like
CDT
and
leap,
it
will
instead
be
much
more
pliable
on
that
front
so
that
that's
the
main
take
home
for
us.
Is
that
we'll
have
that
patch
release
to
fix
the
ship
issues?
We've
been
facing
inside
of
leap,
and
then
we
will
have
a
new
release
of
Dune
upcoming
as
well.
C
B
D
B
B
Absolutely
in
terms
of
like
our
our
repo,
we
have
gotten
feedback
around
Mac
support
issues.
I,
unfortunately,
am
not
well
equipped
with
some
of
the
latest
updates,
but
anecdotally,
it
did
come
up
in
a
meeting
yesterday
that
mikal
one
of
our
teammates
who's,
been
primarily
focused
on
Dune,
has
introduced
a
few
resolutions.
B
Two
issues
related
to
Mac
I
apologize
that
I
don't
have
specific
details
here,
but
that's
another
thing:
I'm
happy
to
bring
to
the
next
update
and,
of
course,
we'll
be
performing
that
release
I'll,
be
working
on
the
release
notes
also
during
that
span
of
time,
so
I'll
be
able
to
speak
more
intelligently
about
it
than
I
am
today,
but
I
do
know
that
there
are
some
of
the
Mac
issues
that
have
been
addressed
in
this
latest
student
release.
I've
just
had
a
chance
to
sync
directly
with
me
Cal,
yet.
C
B
C
C
F
No,
it's
okay,
so
I
don't
use
Dune
just
because
it
does
complicate
things
like
going
through
Docker
and
trying
to
you
know
kind
of
handling
the
file
system
and
also
Dune
has
sort
of
like
different
syntax
than
the
typical
CDT.
So
if
you're,
if
you're
familiar
with
the
CDG,
just
use
a
CDT
I,
don't
we
don't
need
to
kind
of
use
another
step
so
I,
just
personally
don't
use
Dune
at
all,
but
I've
been
able
to
compile
the
CDT
on
my
Mac,
so
I'm
just
been
kind
of
using
the
CDT
natively.
The
only.
F
I
have
to
compile
it
myself
because
there's
no
binaries
built
in
so
a
lot
of
the
Mac
users.
Typically,
it's
like
Brew
install
CDT
and
then,
if
that's
not
available,
they
don't
install
it
because
they're
not
they're,
not
going
and
compiling
the
sort
of
C
plus
code
to
build
their
binaries,
but
I've
been
able
to
succeed
like
succeed,
to
actually
build
it
and
I
just
use
that,
like
natively,
using
Docker
with
the
file
system
and
kind
of
like
there's
just
a
little
bit
more
of
a
headache
and
I.
A
F
F
You
know
a
smart
contract
and
I
just
point
them
to
the
another
compiler
which
is
the
vert,
which
is
like
a
it
comes
with
a
pre-built
binary.
But
again
it's
always
nicer
to
use
this.
The
native
CDT,
so
I
use
both
I
use.
Two
different
compilers
depends
on
the
mood
I
guess,
but
I
don't
use
Dune.
So
that's
that's.
F
No,
they
would
compile,
they
would
still
come.
The
hardcore
ones
would
just
you
know,
compile
their
own
binaries
and
stuff,
and
so
at
least
that
works
before
it
didn't
work,
but
now
it
works
so
and
there's
no
issues
with
compiling
the
CDT.
It's
just
an
extra
step
that
usually
most
developers
don't
do.
B
F
Yeah
for
sure
and
and
I've
actually
gone
one
step
further
is
why
some
sometimes
I've
started
using
a
GitHub
actions
to
do
the
builds
so
that
I,
don't
you
don't
even
need
to
even
have
the
CDT
compiled
on
your
own
computer?
You
just
set
up
a
GitHub
actions
that
will
compile
and
publish
the
binaries
to
your
GitHub
releases,
so
you
just
publish
a
new
tag
on
your
GitHub
repo
and
it
will
compile
and
deploy
your
smart
contracts
directly
into
your
release.
F
So
technically
you
don't
even
need
a
CDT
if
you
use
GitHub
actions
and
then
let
GitHub
in
Ubuntu
do
the
compiling
and
stuff
like
that.
So
I've
actually
not
even
needed
to
have
the
CDT
anymore,
which
is
just
another,
but
that
might
be
the
more
hardcore.
But
it's
a
lazy
hardcore.
It's
not
even
have
CDT.
G
F
G
H
H
So
when
I
did
things
with
Docker
I
had
to
like
turn
everything
off
other
than
Docker,
and
my
code
editor
and
yeah
the
same
things
that
Dennis
said
like
it
just
adds
some
extra
complexity
dealing
with
the
virtual
file
system
and
things
like
that.
So
if,
if
it's
possible
to
pre-compile
those
native
binaries,
make
it
more
convenient
for
people
to
work
directly
with
a
CDT
I
think
that's
always
good.
B
I
know
that's
excellent
feedback,
and
maybe
one
thing
that
I'll
tease
here
is
that
there
have
been
some
early
discussions
around
setting
up
some
form
of
a
round
table
for
developers.
Specifically,
you
know
we
found
a
really
nice
niche
here.
It's
actually
excellent
to
see
a
number
of
new
names,
at
least
not
necessarily
faces
on.
B
This
call
today
means
that
Brian's
doing
the
right
things
here
to
get
you
guys
in
here
and
engaging
with
him
I
think
that
we
will
be
looking
to
introduce
some
sort
of
forum
of
that
capacity,
still
working
with
Nathan
to
decide
whether
what
he's
envisioned
is
a
little
bit
more.
Like
thought,
leadership
and
discussion
versus
really
like
this
more
like
inbound,
collection
of
requirements
and
understanding.
Very
specific
user
needs
to
the
software
that
we're
supporting.
But
that
is
an
update
that
I
hope
to
provide
in
the
coming
weeks.
B
G
E
G
G
G
I
G
D
D
G
D
D
We
are
seeing
huge
Talent
interested
in
blockchain
governance
in
wax
very
engaging
and
vital
discussions
happening
and
the
broader
picture
of
community.
So
there's
a
lot
happening.
You
should
definitely
make
sure
to
join
the
public
groups
and
get
some
of
that
feedback
that
we
get
over
and
over
from
the
community
in
regards
of
our
tooling.
A
A
G
G
Yeah
so
now
I'll
I'll
through
one
of
those
public
groups,
so
I'll,
see
if
I
can
find
you
and
reach
out
so
that
we
can
discuss
a
little
further
so
for
for
the
new
folks,
just
a
you
know,
quick
introduction,
you
might
not
know
who
I
am
so
I'm
a
senior
product
manager
at
enf,
focusing
on
you
know,
block
producers
or
node
operators
is
sort
of
one
of
my
key
areas
of
focus.
So
that's
that's.
Why
I'm
on
these
calls?
G
That's
why
I
want
to
learn
from
you
folks,
the
sort
of
the
way
you're
doing
things
kind
of,
as
I
mentioned,
with
Denise
point
from
a
developer
perspective.
You
know
I
want
to
get
insights
into
those
things
that
are
different
than
our
assumptions.
You
know
like
there's
best
late
plans
and
then
there's
rubber
hits
the
road
right
and
you
guys
definitely
interface
with
that
rubber
a
lot
more
than
we
do
so.
I
appreciate
your
your
engagement
in
these
sorts
of
calls
so
that
we
can
learn.
G
G
As
far
as
what
I
wanted
to
cover
today,
so
there's
three
potential
things.
So
first
I
want
to
just
give
a
quick
status,
update
on
the
resource
model
discussions
and
then
I
wanted
to
we're
kind
of
low
on
a
backlog
of
agenda
items.
So
I
wanted
to
do
a
quick
sort
of
topic,
brainstorm
sort
of
gathering
so
that
I
have
a
list
sort
of
a
backlog
of
things
we
can
cover,
and
then
one
topic
that
would
be
great
to
get
into
today
is
I.
G
Know:
Aaron
expressed
an
idea
last
week
about
read-only
nodeeos
instances,
and
it
looks
like
Aaron
is
here
so,
if
he's
still
around
when
we
get
to
that
I'd
love
to
get
into
that
topic
and
get
an
overview
of
that
all
right,
so
quick
update
here,
oops
Daniel.
Is
it
easy
for
you
to
allow
me
to
share
my
screen.
G
G
So
our
conversations
about
in
the
last
two
sessions
of
this
have
focused
around
resource
model,
pain
points
from
a
node
operator
perspective,
the
basically
the
information
I
gathered
through
those
conversations
have
become
this
doc.
That
is
a
target
audience
of
internal
enf
developers,
basically
to
go
into
the
Gory
details
of
of
the
pain
points
that
node
operators
are
experiencing
and
then
some
you
know,
potential
scope
for
us
to
address.
G
I
want
to
start
with
the
caveat
that
this
is
not
a
commitment
to
delivering
the
user
stories
that
I'm
going
to
list
here
at
this
stage,
it's
just
to
sort
of
show
the
scope
that
we've
identified
through
those
conversations-
and
you
know
I'm,
going
to
talk
about
the
next
steps
before
I
even
go
through.
What's
in
here.
G
Next
steps
are
going
to
include
sort
of
determining
how
these
proposed
changes
would
play
with
other
related
changes
that
we
have
in
the
pipeline
that
that
kind
of
are
in
a
same
space
right,
it
would
touch,
would
touch
similar
parts
of
the
system.
Both
you
know,
by
by
the
enf
grant
recipients,
RFP
RFP
I,
guess
winners
will
say
to
make
sure
that
you
know
we're
we're
kind
of
all
moving
in
the
same
direction,
we'll
of
course
select
which
of
these
initiatives
will
actually
do
we'll
prioritize
it
against
other
initiatives.
G
You
know
and
then
organize
it
into
Target
releases,
do
the
technical
design
and
work
breakdown.
So
those
are
the
next
steps,
but
first
and
again,
I'm
only
really
going
to
show
the
table
of
contents,
because
it's
really
just
the
bullet
list,
piece
that
that
I
want
to
discuss
and
I
want
to
make
this
quick.
G
One
of
these
is
going
to
sound
like
a
new
thing
that
we
didn't
discuss
and
that's
because
I
had
discussed
it
kind
of
offline
with
Denis
in
a
separate
conversation.
So
if
it
seems
that,
like
it
comes
out
of
left
field,
that's
where
it
came
from
so
first
it
seemed
like
the
biggest
sort
of
Point
is
billing
for
failed
transactions
as
a
you
know,
as
a
means
of
at
a
chain
level,
preventing
sort
of
spamming
through
failed
transactions.
G
Next
is
enabling
off-chain
Abuse
Prevention
for
service
nodes.
We
talked
about
basically
nodius,
providing
better
a
more
complete
information
like
failure,
traces
and
better
response
codes
and
not
using
500s,
which
I
think
that
change
may
have
already
been
made,
but
yeah.
So
so
just
things
that
will
enable
off
chain,
at
the
proxy
level
easier
and
more
accurate
Abuse
Prevention.
G
G
Increases
to
to
the
total
available
storage
on
a
Antelope
chain
right
and
so
that
that
one's
a
big
sort
of
undefined
thing
it's
more
more
the
architecture
sort
of
piece
rather
than
an
implementation.
Think
of
this,
as
you
know,
make
a
blue
paper.
It's
a
type
of
type
of
conversation,
lowering
ram
cost
reduction
as
a
short-term
mitigation
for
some
of
these
issues.
So
this
is
really
the
the
ability
to
lower
RAM
cost
reduction
right
and
then
finally,
on-chain
resources
table.
G
So
the
really
I
guess
the
title:
this
should
be
smart
contract
access
to
information
about
account,
resource
usage
and
availability,
so
that
you
know
this
is
that's
pretty
much.
What
I
wanted
to
do
with
this,
this
status,
update
is,
is
show
you
what
those
conversations
turned
into
the
this
document
is
sort
of
being
reviewed
internally
and
will
lead
to
some.
G
G
So,
thanks
again
for
everybody
who's
who
participated
in
those
conversations,
you
know
obviously
very
helpful
to
get
your
perspective
and
and
the
things
that
are,
you
know,
causing
you
trouble
today,
so
that
we
can,
you
know,
know
what
we
need
to
address
foreign.
So
the
next
thing
is,
as
I
said,
we
are
sort
of
light
on
sort
of
the
backlog
of
topics
to
to
address
in
these
calls,
but
I
know
there's
plenty
that
we
could
address
in
these
calls.
G
So
I
wanted
to
do
you
know
a
few
minutes
of
sort
of
open
floor
to
you
know
to
get
people's
thoughts
on
the
sorts
of
things
that
they'd
like
to
discuss
here
again,
just
a
high
level
overview
of
the
intention
of
this.
Is
it's
really
mainly
an
opportunity
for
node
operators
to
you
know,
discuss
together,
you
know,
strategies
that
they
have
yeah
to
you
know
to
make
their
node
operations
more
smooth
or
pain
points,
they've
run
into
that
sort
of
stuff
and
then
secondarily,
but
very
important.
G
For
me,
it's
also
an
opportunity
for
enf
and
myself
specifically
to
to
benefit
from
hearing
those
conversations,
and
you
know
turn
turn
that
into
you
know
future
deliverables
for
into
the
leap
and
and
other
antelope.
You
know
Technologies.
So
with
that
open
floor,
what
topics
would
you
folks,
like
to
see
discussed
in
future
calls.
G
C
C
C
C
My
first
stop
would
be
going
to
your
tool
meth
here
you
know
your
EOS
Nation
tool
and
seeing
who's
actually
live
still,
you
just
grab
some
of
them
or
people
that
you
know,
and
you
put
them
in
and
maybe
they're
a
little
bit
slow
and
then
it
starts
at
the
top
and
slowly
walks
its
way
through
I.
Don't
know.
J
F
A
C
C
C
You
know
appropriate
responses,
but
but
even
if
you've
got
like
you
know,
10
good
guys,
it
doesn't
always
mean
that
you're
going
to
be
getting
the
right
guy
at
the
right
time,
because
somebody
could
go
down
and
then
it
sort
of
hangs
there
for
a
bit
and
gets
a
bit
confused
and
and
and
I'm
talking
about
this.
This
is
not
from
like
how
you
get
your
back-end
block
production
mesh
going.
G
F
Just
for
topics
and
those
Solutions
just
to
talk
about
that
single
resource
sort
of
model
that
we
would
kind
of
model,
you
know
like
kind
of
merge,
net
and
CPU
and
have
let's
maybe
that
one
single
resource
model
so
I
think
that's
a
discussion.
I
have
no
idea
what
the
solution
would
be,
but
I'm
sure
we
can
have
a
good
discussion
on
that
and
the
other
thing
is
just
figuring
out
how
we
can
kind
of
get.
F
You
know
the
chain
a
bit
more
usable
and
kind
of
like
the
what
the
chain
has
used
and
built
with
anchor
and
the
EOS
power-up,
and
try
to
maybe
build
more
native
solutions
that,
instead
of
trying
to
have
third-party
providers
bacon
that
that
missing,
Gap,
there's,
probably
some
help
with
having
the
the
chain
itself
provide
some
of
these
resource
helpers.
I
guess
you
can
say
so.
We
have
an
opportunity
right
now
that
the
gray
Mouse
team
is
working
on
worth
kit
and
better
integration
with
wallets.
F
So
I
think
this
would
be
a
good
opportunity
to
kind
of
really
get
the
feedback
from
Gray
Mass
to
say
like
well.
What,
if
we're
going
to
be
shifting
like
if
EOS
and
Antelope,
is
Shifting
towards
more
of
a
different
wallet
integration?
That's
also
the
opportunity
for
the
chain
to
adapt
and
maybe
improve
a
few
things.
So
I'm
sure
that,
let's
see
if
Aaron
yeah
Aaron
is
here,
I'm
sure
gray,
Mass
has
lots
of
suggestions
and
lines
up
up
with.
F
You
know
how
to
improve
the
resource
model
as
a
wallet
provider
and
a
native
chain,
because
right
now,
a
lot
of
these
toolings
gray
Mouse
has
to
kind
of
provide
it
on
the
side
and
so
yeah
I
think
yeah,
better
wall
integration
with
the
resources,
maybe
an
improvements
on
power-up
or
a
single
One-Shot
transaction.
Who
knows
yeah.
F
Yeah
yeah
and
a
lot
of
a
lot
of
the
the
it's
not
that
complicated,
you
just
say:
hey
I.
Have
this
account
just
make
sure
that
has
resources
for
the
next.
You
know
14
30
days
or
so.
So.
A
lot
of
the
use
cases
are
actually
pretty
simple,
but
we
have
to
use
third-party
tools
because
we
can't
I
can't
use
it
with
the
native
tools
and
avoid
I
think
I
think
a
day
or
two
power-up
was
was
down
and
everybody
was
panicking.
F
H
H
Maybe
you
deposit
into
some
EOS
Nation
account
and
then,
when
you
push
a
transaction
in
Anchor
to
EOS
Nation
node,
it
checks
your
account
to
see
if
you
have
a
CPU
and
it'll
trigger
a
power
up
before
it
pushes
that
action
on
chain
to
help
ensure
it
and-
and
this
would
be
better
than
my
current
system,
which
people
are
using
where
it
doesn't
know.
If
you
need
to
send
the
transaction
it
just
knows.
H
So
that's
something
that
would
be
an
easy
win
and
then
like
anchor,
has
like
the
co-signing
built
in,
but
that
doesn't
work
with
every
application.
It
fails
sometimes
for
various
reasons.
So
I
still
think
we
need
some
kind
of
an
auto
power
up
built
into
the
API
endpoint
as
a
fallback
in
my
opinion,
and
that
would
solve
like
90
of
people's
issues.
H
H
K
We're
probably
going
to
have
the
new
client
sdks
before
this
ever
got
implemented
in
a
server
though
Okay.
So
yeah.
No,
but
but
I
have
a
lot
of
thoughts
here
and
we
can
take
a
lot
of
those
offline
but
to
kind
of
go
back
to
what
Denny
was
saying
like
we're
developing
the
client-side
stuff
right
now,
and
we've
also
built
a
server-side
implementation
to
listen
to
that
client-side
implementation.
But
it's
just
something
that
we
built.
K
It's
not
fully
fleshed
out,
so
we
could
really
use
the
server-side
implementation
to
be
native
to
that
co-signing
process.
So
that
way
any
node
operator
could
run
this.
Maybe
the
protocol
is
iterated
on
how
the
how
it
goes
back
and
forth
could
be
improved
upon
with
external
eyeballs
and
that
I'm
specifically
talking
about
co-signing
at
this
point
we
could
have
that
baked
in
so
that
way,
it's
just
something
that
API
operators
could
turn
on
and
client-side.
K
You
could
just
say,
get
supported
apis
against
whatever
API
you're
using,
and
it
would
tell
you
if
that's
available
and
it
can
handle
resources
in
that
manner.
As
far
as
power-up
goes
there
like
can
be
client-side
plug-ins.
That
can
test
the
transaction
using
compute
transaction
model
and
automatically
append
a
power-up
action
before
the
user
even
sees
the
action,
so
we
can
kind
of.
If
we
want
users
to
go
directly
to
power
up
like
client-side,
we
can
make
that
happen.
G
So
I'm
going
to
jump
in
again
sort
of
facilitation
thing
to
to
keep
moving
I
took
notes
on
that
context,
so
that
I
can
sort
of.
Let's
you
know,
start
start
a
follow-up
conversation
on
that
warm.
If
that
makes
sense
right,
we
I
do
want
to
move
into
the
read-only
nodeeos
instances
Thing
by
9,
45
Eastern.
So
we've
got
about
three
minutes
left
to
document
any
other
topics
that
we
would
want
to
get
on
the
backlog.
K
I
can
throw
some
out
real,
quick,
the
resource
payer
thing
that
was
in
2.1.
That
is
not
in
leap
right
now.
That
would
be
nice
to
have
to
not
have
had
no
op
actions.
If
we
can
raise
a
discussion
around
that
going
back
to
the
peer-to-peer
stuff
if
it
would
be
nice
to
have
a
method
to
guarantee
connectivity
between
two
servers,
something
like
the
peer
key
just
to
kind
of
try
to
illustrate
what
I'm
talking
about.
K
Where,
like
we
have
public
peer-to-peer
nodes
and
they're
full,
but
if
I
could
specify
a
key
on
one
of
our
internal
nodes
and
then
it
could
guarantee
a
connection
that
could
go
over
that
limit.
That
would
help
us
connect
to
our
public
nodes.
You
know
and
maybe
even
trusted
other
people.
I
know
the
peer
key
exists,
but
it
doesn't
do
exactly
that
so
topic
there
I
have
one
more,
but
I
don't
remember
it.
So
if
that
comes
up,
I'll
leave
a
message
while.
G
K
We
run
operator
is
running
public,
peer-to-peer
nodes
and
they're
publishing
it
like
the
validators,
picking
it
up
and
everybody's
connecting
to
it.
It
gets
full
and
then
your
internal
connectivity,
like
your
other
peers,
like
let's
say
you
have
10
public
peer-to-peer
nodes,
if
they're
all
full,
they
can't
connect
to
each
other.
So
if
they
all
had
a
key
specified
that
allowed
a
guaranteed
connection
between
between
all
10,
then
you
could
create
your
own
kind
of
a
private
mesh
while
still
allowing
public
connectivity.
So.
K
C
G
J
K
F
One
more
I
want
to
sneak
in
before
we
get
to
the
next
topic.
Is
the
contract
error
handling
on
other
contracts?
So
one
of
the
things
that
we're
noticing
is
that
we
we
interact
with
other
smart
contracts
and
whenever
there's
an
error,
usually
it's
an
error.
That's
very
not
explicit,
and
it
has.
We
have
no
idea
what
it
is
and
we
don't
know
which
contract
is
causing
that
error
and
like
even
just
knowing
the
contract
account
and
the
contract
name
like
the
action
name
to
know.
J
Brian,
along
with
those
those
notes
just
indicate,
like
Matt's,
already
had
this
idea
of
like
a
back
Trace,
which
would
be
actually
that
we
could
just
throw
into
the
into
the
trace
when
something
like
that
happens
and
point
right
to
to
where
you
want
to
be
and
provide
context.
So
it's
I
think
an
easy
win.
Yeah.
G
Excellent
great
all
right
so
kicking
into
the
topic
of
read-only
nudious
instances
there
so
I
dropped
about
15
minutes
early
on
last
week's
call
and
I
guess
in
that
time
Aaron
introduced
this
topic
as
an
idea.
That's
all
of
the
context.
I
have
at
this
point.
So
with
that
Aaron.
Can
you
take
us
away
on
read-onlyn,
odious
instances,
sure.
K
I
think
it
was
in
Steam
just
to
give
some
background.
There
was
a
flag
you
could
set
when
launching
an
instance
of
the
server
that
was
read
only
and
it
would
prevent
essentially
the
node
from
syncing
from
the
network
and
like
doing
all
the
block,
processing
and
whatever,
but
it
made
that
process
serve
as
purely
a
read-only
node
to
the
state.
K
We
may
have
some
of
the
similarity
right
now
with
how
threading
works
and
some
of
the
processes,
but
we
still
have
in
our
operations
some
servers
that
run
many
nodeo's
instances
and
each
need
their
own
State
file.
Many
of
those
nodeeos
instances,
don't
so
as
a
topic
of
conversation
and
I,
don't
intimately
know
the
architecture
of
leap,
so
I
may
be
making
some
naive
assumptions
here.
K
There
would
be
some
use
if
it
was
possible
to
spin
up
a
node
us
instance,
and
it
was
read
only
it
provided
all
of
the
read
capabilities
of
nodeeos
without
any
of
like
the
syncing
capabilities,
essentially
as
well
as
push
transaction
like
that
wouldn't
work,
but
then
that
process
alone,
like
you
know
it
with
its
full
utilization
available,
would
be
able
to
serve
any
reading.
Queries
like
get
tables
or
get
accounts,
or
anything
like
that,
which
would
then
alleviate
pressure
off
of
the
nodes
that
are
actually
syncing
and
writing.
K
So
this
would
create
a
scenario
where
I
could
have
one
server
that
is
running
one
full
being
a
terrible
term
for
this
because
fold,
node
means
million
other
things,
one
node
that
is
syncing
and
then
multiple
read-only
processes
and
then,
through
the
proxy
layer.
We
would
direct
certain
read
queries
to
those
read-only
nodes,
just
to
purely
reduce
pressure
on
the
Node.
That's
actually
doing
the
syncing
and
the
writing.
G
G
K
Know
how
antelopes
database
processes
work
exactly
so
I,
don't
even
know
if
that's
possible,
but
we've
seen
and
used
other
implementations
of
this
kind
of
architecture
before
and
as
we
were
talking
about
scaling
concerns
last
week.
That
was
one
idea
that
came
to
mind
so
I
figured
I
would
bring
it
up
as
maybe.
L
I
agree
with
that
can
I
also
add
I
brought
this
up
before,
but
it
belongs
in.
This
context
is
blocks
only
relay
nodes,
don't
even
need
any
state
or
very
little
State
just
to
validate
that
the
block
is
valid,
so
it
needs
some
little
bit
of
state
and
then
you
can
transmit
blocks
fast
without
worrying
about
any
transactions
or
any
big
state
file
or
whatever.
So
we
could
improve
the
E
peer-to-peer
network
block
propagation.
Somehow
again,
I,
don't
know
how
to
architect
that,
but
logically,.
K
L
A
K
G
K
And
there
may
be
more
radical
approaches
to
this.
That
might
make
more
sense
like
if
the
state
itself
could
be
streamed
out
to
something
that's
accessible
by
other
things.
You
know:
we've
had
these
types
of
plugins
in
the
past,
that
stream
to
like
a
SQL
database
or
something
yeah,
but
if
it
could
be
a
data
provider
that
stream
like
Save
State
in
a
way
that
other
consumers
can
consume
State,
then
we
might
not
even
like
we
could
have
other
external
services
that
run
that
read
that
state
and
serve
it
out.
L
G
L
I
think
depends
on
you
know
if
we're
looking
at
I
suppose
smaller
blockchains
or
ease
of
use
for
spinning
up
a
new
chain,
and
you
don't
have
all
these
load
things
then.
Obviously,
if
you
can
just
keep
everything
in
one
binary,
then
it
makes
it
very
easy
for
someone
to
to
get
on
board
or
are
we
targeting
the
well
we're
planning
to
grow
Antelope
into
these
massive
huge
clusters
of
you
know,
you
need
hundreds
of
machines.
G
J
J
So
you
can
take
a
look
at
that
and
and
provide
feedback
if
you
like,
but
that's
that's
coming,
so
that's
kind
of
exciting.
The
second
one
is
an
implementation
that
is
just
waiting
to
be
merged.
That
will
come
out
in
the
next
major
release
which
will
propagate
blocks
after
header
validation,
which
will
greatly
improve
black
population.
J
That's
actually
done
even
off
the
main
thread
so
that
it
can
happen
without
even
interrupting,
what's
currently
happening,
anticipating
being
a
huge
Improvement,
there
is
we're
talking
a
potentially
I
think
we're
talking
about
this
week
of
releasing
patch
release
of
3-1,
which
will
include
this
PR,
which
is
about
to
be
merged,
probably
right
after
this
meeting,
which
is
also
should
help
a
block
propagation.
So
they're
just
really
related
to
the
topics
that
we've
been
discussing.