►
From YouTube: EOS Node Operator Roundtable - February 1st, 2023
Description
This week the EOS Node Operator Roundtable updates the community on software development and has a detailed discussion on CPU execution limit changes, Optimizing “get_table_rows” and how to best to debug these issues.
00:00:00 Start
00:00:02 Welcome to the Node Operators Roundtable
00:00:36 Software development update
00:08:45 CPU Execution Limits technical discussion
00:41:37 Optimizing “get_table_rows”
00:52:04 Wrapping it up and next week's topics
00:57:28 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
You
go
there,
you
go
so
yeah
welcome
everybody
Brian
will
be
joining
shortly.
In
the
meantime,
it's
been
brought
up.
Just
a
couple
topics
we
might
want
to
discuss.
One
is
some
release
updates,
Dune.
We
can
hear
hear
from
Stephen
on
on
the
news
there
Ubuntu
18
support
and
some
topics
suggested
from
Matthew
regarding
changes
to
3.2
that
are
that
had
caused
some
configuration
issues,
but
maybe
we
can
start
with
the
easy
release
updates,
Stephen.
C
So
I
guess
it
was
last
week
or
the
week
before
we
released
V
1.1.0
for
Dune
main
thing
that
I
had
mentioned
previously.
There
was
just
greater
flexibility
around
the
version,
dependency
across
leap
and
CDT
repos.
It's
a
couple
of
other
bits
that
you
can
see
here,
including
some
packaging
for
Windows.
Just
note
there
that
the
chocolatey
approval
from
their
team
is
still
in
process,
which
is
why
the
package
is
attached
directly
to
this
release.
Right
now
and
beyond
that,
you
can
see.
C
Those
are
some
of
like
the
big
take-homes
there
I
think
in
the
next
release,
we'll
look
to
kind
of
catch
up
on
the
Mac
side
in
terms
of
packaging.
There's
some
work
in
progress
there,
but
it
didn't
quite
make
the
cut
so
just
some
incremental
progress.
There
we've
got
some
new
teammates
that
have
made
some
really
meaningful
contributions.
A
A
B
Brian
relatively
short
conversation
unless
and
it's
it
should
be
relatively
short,
either
way.
I'll
want
me
to
jump
into
it
real,
quick
sure
so
Ubuntu.
The
original
goal
we
had
set
was
that
we
would
support
two
active
releases
of
Ubuntu
for
the
block
producers.
So
that's
now
2204
and
2004..
So
we're
now
coming
out
saying
we'd
like
to
deprecate
1804.
B
That
doesn't
mean
they're
dropping
all
support,
you're
happy
to
pay
for
it,
they'll
happy
to
take
your
money,
but
we
would
like
to
say
that
we
would
like
to
deprecate
and
say
we're
we're
not
supporting
1804
and
possibly
even
as
early
for
you
know,
so,
for
the
Ford
Auto
release
that
will
come
out
sometime
around
March.
We
want
to
say:
1804
will
not
be
supported
for
that
release
and
we
want
to
know.
You
know,
like
it's
kind
of
like
how
do
you
tell
if
someone's
using
a
server
you
unplug
it.
B
So
this
would
be
the
point
where
we're
waiting
to
hear
someone
start
screaming
saying:
oh,
my
God
I
can't
get
off
of
1804..
My
life
depends
on
it,
so
we're
cueing
that
up,
because
we
want
to
tell
you
now
it's
deprecated
and
it
will
go
away
in
the
4.0
release,
which
will
come
out
in
the
marchesh
time
frame.
C
B
C
E
B
Will
exercise
self-flagellation
afternoon
so
the
so
it
sounds
like
everyone's
okay
with
it.
We
probably
will
try
to
run
a
little
tighter
Windows
because
it
helps
on
the
Boost
libraries
and
the
builds
we're
coming
out
with
some
strategic
strategic,
build
changes
which
you
know
will
make
a
lot
of
this
simpler
going
forward.
B
It
is
the
Crux
of
a
lot
of
the
engineering
discussions
that
we
debate
all
these
builds
and
releases,
and
you
know
her
pulling
teeth,
dashing
and
all
that
good
stuff.
So
thank
you.
It
sounds
like
we've
we're,
okay
with
that
I,
don't
know
how
we'll
communicate
that
more
broadly
Daniel
other
than
people
can
watch
this
video
Brian.
This
is
your
area.
B
You
might
want
to
communicate
with
Patty
and
Zach
and
see
if
they
they
want
to
get
it
into
the
EOS
everything
weekly
update
or,
however,
we
generally
communicated
if
they're
you
know.
If
we
want
to,
you
know,
go
into
the
the
block
producer
channels
and
just
start
to
you
know.
You
know
telegram
that,
and
you
know
maybe
Matthew
can
help
you
in
some
of
the
more
esoteric
channels.
B
F
B
Again,
they
don't
have
to
do
the
upgrade
to
Stephen
like
when
we
came
out
with
this
and
it
only
compiles
on
2004
and
2204
when
they
go.
Oh
gee
I'm
only
on
1804.
The
answer
is
okay.
You
don't
have
to
do
the
upgrade,
but
by
the
way,
when
we
get
to
that
consensus,
upgrade
5.0,
it
will
remember
you
will
need
to
be
on
at
least
20
before.
A
E
D
So
like
when
we
did
the
last
census
upgrade
we
I
think
I
have
one
person
complained
that
1604
was
not
supported
anymore
and
I
told
them
to
go
away
just
upgrades.
So
anyway,
I
don't
have
a
problem
with
this
I
used
to
work
in
HP
software,
and
we
have
exactly
this
discussion
every
time
about
every
release
that
every
customer
wanted
sport.
Can
you
still
support?
Solaris,
hey,
no
okay,
perfect
I,
love
that
yeah,
so
I
I
understand
the
whole
discussion,
so
I'm
good
with
it.
So
let's
just
stick
with
the
two
releases
and.
A
B
F
F
D
D
The
the
release
notes
was
lacking
in
this
area
to
explain
the
impact
of
the
change
and
anyway,
at
the
end
of
it.
There's
kind
of
two
issues
opened
one
about
this
change
specifically
and
one
about
adding
more
debugging
to
make
it
easier
to
debug
these
sorts
of
issues.
So
Kevin
and
I
had
quite
a
discussion
yesterday
on
this.
So
I
don't
know
if
the
best
way
to
approach
this,
maybe
Kevin.
D
You
want
to
summarize
the
thinking
behind
what
was
the
changes
in
3.2,
and
you
know
that
we
can
discuss
from
there.
I
think
it's
good
to
discuss
so
that
everybody's
aware
of
what's
changed,
because
the
node
operators
are
going
to
need
to
make
a
configuration
change
when
they
upgrade
the
3.2,
which
you
know
I
didn't
do
ahead
of
time.
So
all.
G
You
know,
and
because
of
that
there
was
a
lot
of
changes
that
were
made
so
there's
a
there's,
a
limit
for
ABI
serializer
Max
time.
That
was
added
at
some
point
in
the
past
that
limits
how
long
the
ABI
civilizer
is
allowed
to
run.
And
that's
the
point.
That's
the
amount
of
time
that
the
the
block
is
being
converted
from
its
binary
form
to
its
Json,
expanded
form
with
all
the
action
data
expanded
as
well
within
within
that
Json.
G
That's
that's
that
limit
and
that
all
happens
on
the
main
thread,
even
as
as
of
today,
even
the
very
main
branch
of
the
code
still
does
that
all
on
on
the
main
thread.
Now
over
time,
there
was
added
at
hcp
Max
response
time,
which
was
which
originally
was
this
idea
that
we
would
expand
that
option
to
eventually
include
the
entire
time
that
an
HTTP
request
was
happening.
Its
initial
implementation,
though,
was
was
much
simpler.
G
It
was
simply
to
limit
the
amount
of
time
of
actually
converting
binary
data
into
Json
of
the
form
that
weren't
covered
by
the
API
serializer.
So
there
are
different
ways
of
converting
things
into
Json.
One
is
using
this
API
serializer,
which
expands
the
action
data,
there's
putting
things
into
Json
without
doing
that,
step,
which
is
just
taking
binary
and
converting
it
direct
to
Json,
not
using
Behavior
serializer.
So
this
new
limit
originally
only
controlled
how
long
it
took
for
a
conversion
of
data
to
Json
outside
of
the
API
fertilizer
stuff.
G
So
it
had
a
very
limited
use
case
in
terms
of
what
it
actually
enforced,
but
the
idea
was
always
when
there
was
originally
put
in
that
it
would
cover
the
entire
time
frame
that
there
was
an
issue,
it's
pr96
which,
unfortunately,
for
whatever
reason,
did
not
make
it
into
the
release
notes
at
all.
So
there
there
is
I,
think
well,
there's
a
description
on
that
PR
that
that
I
wrote
that
tried
to
explain
this
now,
as
Matthews
pointed
out,
it
could
have
been
better
and
I
agree
with
that.
G
G
10
millisecond
run
times,
particularly
these
just
want
to
think
about
as
like
get
table
rows,
and
so
it
would
just
run
for
10
milliseconds
and
return
as
many
rows
as
it
could
within
that
10
milliseconds
and
return
that
data
to
you
now,
sometimes
what
it
could
return
to
you
in
10
milliseconds
was
actually
no
rows
and
you
should
just
get
nothing
back,
but
that
that
was
you
know.
People
worked
around
this
forever.
They'd
have
to
make
a
call
and
see
what
the
nor
the
war
is
and
then
make
another
call.
G
Unfortunately,
there's
this
whole,
like
you
know,
Corner
cases
of
data
could
be
added
between
those
calls
blocking
process
anyway.
So
one
of
the
things
that
happened,
this
PR,
which
is
kind
of
like
what
it's
described
as
mainly,
is
that
in
a
number
of
API,
endpoints
and
they're
listed
in
that
that
pull
request
that
we
we
removed,
that
hard-coded
10
millisecond
limit
and
instead
said
well,
we
will
we
will
now
honor
the
HTTP
Max
response
limit
instead
of
this
hard-coded
limit.
G
Now
we
also
provided
for
each
of
those
a
new
Option
within
the
request
where
the
the
requester
could
say
how
long
if
they
wanted
to
limit
that
particular
call,
and
so
then
it
would
take
the
minimum
of
the
node
operator
configured
Max
response
time
and
the
limit
requested
in
the
in
the
URL.
So
that
was
one
part
of
that
pull
request.
The
other
part
of
that
poor
request
was
to
actually
honor
that
HTTP
Max
response
time
across
all
chain,
API
endpoints,
including
get
blocked.
G
Now
what
that
means
is
that
gibblog
used
to
be
limited
really
only
by
the
API
serialization
time.
It's
now
limited
by
the
minimum
of
Max.
A
response
time
and
ABI
Mac
serialization
time,
and
so
that
change
is
what
Matthew
tripped
over
was
the
fact
that
I
I
assume
he
had
ABI
Max
serialization
time
set
rather
large
I
think
a
lot
of
people
do
and
they
had,
and
you
had
Max
response
time.
D
So
so
yeah
so
like
the
the
why
we
did
what
we
did
is
good
background.
I
I
think
the
I
guess
the
the
request
from
my
side
is
well.
Can
we
go
back
one?
Can
we
easy
thing?
You
can
go
back
and
just
revise
the
release,
notes
for
3.2
and
just
you
know,
add
a
few
notes
in
there.
I
think
that
would
be
good.
So
you
know
we
capture
this
later
and
then
two,
you
know
okay.
Well
now
you
start
we
started
discussing
this.
You
know
a
little
bit
ago.
D
It's
like
maybe
we
would
need
different
limits
for
git
Block
versus
get
table
rows
because
get
table
rows
can
be.
You
know
huge
and
generate
huge
load
and
I.
Don't
know
I,
don't
have
any
control
over
that,
but
you
know
get
Block
it's
like
well.
Somebody
wants
to
block
then
I'll
send
them
the
block
whatever
that
amount
of
time
it
takes
it.
D
It
feels
to
me,
like
those
are
two
different
kind
of
requests,
maybe
I'm
wrong,
but
I
thought,
maybe
you
know
I-
would
bring
that
up
in
case
other
people
have
opinions
on
thoughts
here
and
I'd
really
like
to
hear
from
Aaron
as
well
on
this
since
Aaron.
You
know
you
get
tons
of
API
requests
and
I
know
you're.
Looking
at
lots
of
details
on
this,
maybe.
H
H
So
I
mean
I,
think
I
preferred
the
previous
Behavior,
because
then
you
have
this
Global
limit
that
throttles
all
the
other
requests
like
get
table.
Rows
like
you
were
concerned
about,
and
then
git
block
is
kind
of
this
special
thing
unto
its
own.
For
that
reason,
I
guess
one
alternative
I
can
potentially
offer
is.
Could
we
have
a
get
raw
block
like
we
have
a
get
raw
ABI
call
and
then
maybe
let
the
client
handle
these
serialization.
So
that
way,
this
isn't
even
just
as
heavy
of
a
call
I
know.
That's
a
long-term
fix.
H
G
Yeah
I
think
that's.
We
won't
talk
about
that.
I
think
there's
already
an
issue
somewhere
about
adding
the
get
raw
block,
and
we
should
be
doing
that,
particularly
since
even
our
ABI
serialization,
that
we're
doing
is
happening
at
the
the
time
of
the
the
get
Block
call
not
at
the
time
of
when
the
block
was
created.
So
the
Avis
that
we're
actually
even
using
for
that
serialization,
isn't
even
the
correct
apis
which
results
in
not
all
the
data
actually
being
expanded
correctly.
G
Where
a
client
you
know
if
he
was
using
the
wall
could
probably
could
certainly
do
a
better
job
of
that
in
terms
of
like
knowing
which
ABI
should
should
be
used
for
for
Mark
and
and
most
of
the
history
Solutions
out
there,
you
know,
do
a
much
better
job
of
that
than
the
actual
get
Block.
Call
that
nobody's
provides,
which
is
you
know
in
buggy,
it
is,
is
maybe
the
way
to
describe
them
right.
H
If
the
kit,
if
git
block,
could
mirror
that
or
the
trace,
api's
output
or
something
like
it
could
mirror
the
get
Block
call
that
might
be
a
way
to
further
optimize
that
and
then,
if
there
was
some
sort
of
trimming
on
that,
you
know
we
wouldn't
be
able
to
offer
every
block
at
that
size
because
I
think
the
trace
API
for
use.
If
we
did,
that
is
something
like
70
terabytes
or
something
because
it's
everything
unfolded
and
deserialized,
but
a
limited
subset
of
that
as
I
was
just
doing.
G
Yeah,
it
is
it's
much
faster,
plus,
it's
all
multi-threaded
and
none
of
it
hits
the
main
thread,
so
it's
faster
and
it
doesn't
even
interfere
with
anything
else
that
nobody's
is
doing
and
it
can
and
it
can
handle
as
many
threads
as
you
throw
at
it.
So
you
know
you
can
you
can
really?
You
know
service
a
lot
of
requests
on
that
endpoint,
but
you're
right?
It
is
a
different
format
of
of
the
git
block.
You
know
the
data
it
provides,
although
similar
is
not
the
exact
same
yeah.
H
I
mean
I,
know
I
kind
of
dove
into
alternative
ideas.
I
had
which
wasn't
necessarily
the
point,
but
for
feedback
like
I
do
think
that
having
get
Block
be
able
to
service
blocks
and
having
get
table
have
some
other
kind
of
or
everything
else
have
some
other
kind
of
limit.
Maybe
the
block
is
moved
to
a
different
name
space
and
we
have
time
limits
per
namespace
or
something
along
those
lines.
I.
G
D
Yeah
I
mean
the
challenge,
is
you
know,
serving
requests
in
a
reasonable
way
and
syncing
blocks
are,
you
know,
are
in
Conflict,
so
there's
never
a
perfect
solution.
Yeah
the
solution
that
I
have
been
talking
about
a
lot
is
you
know
one
node
does
one
thing
and
yeah
you
limit
the
impact
right,
so
you
never
put
a
block
producer
node
available
to
the
public.
Who's
gonna
run,
stupid
API
requests
against
it,
so
yeah.
G
And
I
think
that
was
a
mistake
that
happened
in
the
past
in
terms
of
like
paying
out
hacker
some
some
metals.
The
fact
that,
well,
you
know,
hey
I,
can
do
an
API
request
and
pause
your
block
production.
Well,
okay,
yeah!
You
should
never
really
do
that
so
yeah,
but
yeah.
Instead,
we
tried
to
fix
it
right
and
she's
like
yeah.
D
Yeah
so
I
think
maybe
we
should
I'll
propose
you
guys
can
discuss
you
know.
Is
it
time
to
revisit
that
decision
and
we
put
a
whole
bunch
of
knobs
in
here
to
prevent
that,
but
preventing
that
was
not
the
right
thing
and
it
should
just
be
clearly
documented
that
never
run
a
block
producer
connected
to
any
API
endpoint.
D
That
you're
gonna
abuse
right
be
very
careful
about
what
API
requests
you
send
democracies
with
and
then
using
that
as
the
Baseline,
then,
let's
review
all
the
configuration
and
how
things
are
handled
and
then
maybe
change
some
Behavior
or
remove
some
extra
configuration.
That's
not
needed
or
whatever
yeah.
F
I
was
going
to
ask
ask
a
question
related
to
that.
It's
it
seems
like,
and
maybe
a
I
didn't
follow
everything
yet
to
be
honest,
but
it
seems
like
some
of
this
is
caused
fundamentally
by
the
fact
that,
like
we
might
actually
want
different
behavior
for
different
kinds
of
nodes.
Is
that
is
that
right,
yes,
correct
and
so
to
your
point.
E
Right
but
we're
still
always
so
and
I
mean
it
just
kind
of
opens
up
and
lets
go
and
oh
God
don't
enable
product
producer
API,
because
then
that
turns
on,
you
know
switches
that
at
least
they're
isolated
in
a
namespace.
But
what,
if
it
Moore
just
said,
look
if
you're
running
block
production
if
I
see
that
I'm
configured
to
you
know
schedule
plot
production
shut
down,
all
that
I
mean
don't
shut
down,
get
him!
E
Oh
because
we,
you
know,
that's
a
fundamental
one
that
you
you
know
at
least
we
could
use
to
monitor
but
shut
down.
All
the
rest
of
if
blot
production
is
the
concern,
that's
kind
of
crippling
the
thought
process
of
well.
That's
why
we
did
it
just
okay,
you're
signing
blocks.
We
take
care
of
that
for
you,
you
want
to
know
how
happy
your
API
doesn't
work,
because
you
shouldn't
do
that
on
a
block
producer.
E
G
That
maybe
an
easier
way,
the
the
con
of
that
is
the
fact
that
you
know
people
use
like
a
private
Network
for
like
app
development
and
that
sort
of
thing,
so
you
know
you,
you
don't
want
to
force.
You
know
somebody
that's
wanting
to
just
run
some
little
chain
and
do
a
simple
little
test.
You
actually
have
to
run
two
nodes
right,
one,
that's
doing
their
block
production
quote
unquote,
you
know
producing
either
blocks
and
then
another
to
do
their
API
calls.
E
Doesn't
matter
well,
that's
more,
why
I
say
is
I
mean
if
you
default
and
say
that
it
won't
do
it
in
a
blood
production,
but
if
you
want
to
over
override
it
and
okay,
you
don't
want
us
to
disable.
All
of
that
and
you
have
block
production
enabled,
which
is
the
default.
Oh
you're,
also
signing
with
the
default
EOS
key
or
whatever
it
is
that
comes
you
know,
I
mean.
Is
that
a
it's?
The.
E
G
H
One
thing
we
do
that
I've
always
kind
of
wanted
it
to
do
by
default,
is
at
the
root
endpoint
like
the
slash
with
no
path
we
sort
of
get
info
out
there
like.
If
you
go
to
eos.grayms.com,
it
shows
you
get
info
like
that.
Right
is
a
very
logical
place
to
just
put
the
info
like
if
we
want
to
make
it
that
much
more
special.
Let's
make
get
info
the
root
API
call
of
it.
E
G
E
E
E
F
Have
like
in
a
really
rough
form,
I'm
gonna
have
to
probably
do
some
offline
discussion
to
to
refine
it,
but
I
wanted
to
make
sure
I
understood
one
thing,
because
I
was
going
to
ask
the
question
and
then
it
seemed
like
you
guys
kind
of
answered
it
which
is
like.
Why
do
BPS
need
to
be
running
get
info?
It
sounded
like
it's
mostly
for
internal
monitoring.
Is
that
accurate,
okay.
D
G
H
And
one
comment
regarding
the
idea
of
modes
like
operating
modes:
I
think
rather
than
that
being
a
development
thing,
it
could
be
an
educational
thing
just
to
let
people
know
this,
although
it
would
be
cool
to
have
Flags.
You
know
you
set
developer
mode
and
how
everything's
running
you
set
BP
mode,
and
now
it's
only
the
producer
plug-in
and
The
Limited
subset
of
apis.
D
What
I've
noticed
is
like
looking
at
the
cosmos
chain,
they're
very,
very
clear
about
how
you
need
to
run
a
three-tier
architecture.
Here?
Is
your
public
endpoints,
here's,
your
private
peering
things
and
here's
your
block
validator
at
the
very
back
and
it's
protected
by
its
multiplayers?
Okay,
we
do
the
same
thing
in
EOS,
but
that
where
is
it
documented
anywhere
on
the
developers.esio?
Nowhere
right,
so
other
teams
just
solve
this
problem
with
a
very
good,
clear
documentation
that
explains
the
Russian
aldehyde
and
setting
up
this
kind
of
consistent.
F
Yeah
I
mean
I,
think
you
know
my
my
gut
reaction
to
that
is
that
it
makes
sense
that,
like
a
BP
level,
node
operator
would
need
to
or
or
at
least
benefit
from
understanding
what
the
flags
are
and
why
you
would
set
them.
You
know
that
sort
of
thing,
but
you're
sort
of
like
you're
Dev,
you
know
potentially
can
get
away
with
not
knowing
those
things.
If
there's
some
easy
smart
default
that
you
know
anyway,.
D
You
know
because,
like
at
the
end
of
the
day
like
like
I,
said
whatever
the
the
ABI
serializes
time
to
2000
I,
don't
know
there
was
some
discussion
in
the
telegram
group.
I,
don't
know,
put
two
thousand
I,
don't
know
it
seems
to
work
great
right.
It's
not
like
I
did
an
in-depth
study
to
figure
out
what
the
right
value
is
there.
D
F
D
E
H
E
I'll
say
this:
I
even
have
ship
nodes
that
are
with
console
logging
or
without
maybe
apis
even
have
that
same,
but
some
things
still
require
that
which
dramatically
changed
the
ship
logs
and
it
changes
the
nodes,
so
like
say,
I'm
finding
that's
actually
a
separate,
dedicated
role
and
I
need
to
know.
Oh
I
can't
move
from
this
ship
server
to
that
ship
server
because
they're
not
the
same
so
I,
don't
know
if
that
granularity,
but
I.
C
D
E
F
E
Sort
of
thing
they
are
I
mean
you've
got
major
roles
like
the
plugins
I
mean
that's
really
kind
of
what
a
lot
of
it
is
your
ship
plug-in
peer-to-peer?
You
know
HTTP,
but
then
you've
got
the
different
options
underneath
there,
which
are
more
like
flags
and
config
phones,
but
they
actually
are
pretty
impactful
to
things.
F
Yeah
so
I
can
imagine
you
know
the
minimum
viable
here
just
being
documentation.
That
says
you
know
if
you
are
intending
to
do
this
here
are
the
flags.
You
need
right,
that
sort
of
thing,
and
then
you
know
a
more
I.
Don't
know
sophisticated
option
which
may
or
may
not
be
a
good
idea
is
to
actually
like
just
build
them
in,
as
some
kind
of
you
know,
distinct
option
that
sort
of
bundles
features.
So
here's
what
I'll
do
with
regards
to
this
I'll
do
some.
F
You
know
node
operator
folks
to
generate
and
and
refine
a
list
of
those
conceptual
roles,
because
I'm
sure
you
guys
have
already
discussed
this
many
times
over
and
and
it
won't.
It
won't
be
too
hard
to
sort
of
generate
that
the
hard
thing
will
probably
be
just
consolidating
to
the
smallest
possible
list
that
covers
the
largest
practical
use
cases
so
I'll.
F
Take
that
on
the
other
action
item
that
I
captured
as
an
obvious
thing
that
needs
to
be
done
is
I
will
go
back
and
revise
the
3.2
release,
notes
just
to
more
clearly
call
about
what
we
actually
did
with
this
and
then
I
did
capture
a
lot
of
the
ideas
and
specific
requests
related
to
this
issue,
but
they're,
currently
pretty
rough
due
to
just
some
gaps
in
my
understanding.
So
that's
going
to
also
require
me
to
do
some
offline
kind
of
checking
with
people
to
fill
it
in
so.
A
D
A
F
G
G
Well,
I
I
would
contend
that,
like
we
should
fix
kind
of
get
blocked.
The
way
it's
working
right
now,
I
think
is
to
clearly
be
described
as
a
bug.
So
you
know
that
would
be.
My
recommendation
is
that
we
get
that
in
the
next
patch
release.
Is
we
we
fix
that
small
little
behavior
that
get
blockages
activity
right
now.
A
G
A
A
I
Yeah
I
can
I
can
just
just
quickly
so
most
of
the
front
ends
I'm
sure
Aaron
realized
this
as
well
is
a
lot
of
the
front
ends,
because
there's
only
limitations
on
how
to
request
table
rows
on
the
Node
EOS
providers.
They
have
to
either
go
to
diffuse
or
appear
in
or
a
custom
version
of
a
history
Premiere
because
they
can't
actually
get
specific
data.
Like
let's
say
you
want
to
get
multiple
tokens
from
your
balance.
I
You
literally
have
to
do
like
10
calls
if
you
want
to
get
10
token
balances,
because
you
can't
like
craft
a
get
table
Rose
properly
to
get
multiple
different
things.
So
one
of
the
the
big
use
cases
just
kind
of
like
a
get.
Many
like
give
me
10
different
things
that
have
different
ranges,
like
my
EOS
token
balance
something
else
and
something
else
right
now.
I
You
can't
do
that
because
you
have
to
do
like
three
different,
unique
calls,
because
the
only
way
that
you
can
get
a
table
row
is
just
doing
a
lower
and
an
upper
bound,
and
it's
really
not
that
flexible,
so
I'm
sure
Aaron
sees
it.
Just
people
just
are
brutalizing
the
endpoints
because
it
just
can't
actually
formulate
a
proper
request,
so
maybe
there's
some
ways
that
we
can
kind
of
optimize.
If
we're
going
into
the
optimizating
route
of
you
know,
optimizing,
get
block
and
get
info
and
get
table
rows.
E
I
can
even
tell
you
we
internally
abuse
it's
not
because
you
know
I
mean
we
do
data
Gathering
and
because
they're
local
land
that
zero
millisecond
latency
means
I,
can
rip
the
out
of
an
API
get
table
and
I
mean
I'll
count.
Eight
million
records
every
five
minutes
and
calculate
statistics
off
of
them.
So
it's
amazing
how
much
you
just
have
to
abuse
an
API
and
you.
I
Would
still
need
to
put
some
limits,
you
know
to
prevent
abuse
and
then
be
like
a
maximum,
a
thousand
rows,
and
you
know
there
was
this.
Definitely
a
8
000
row
request
is
a
little
bit
too
intense,
but
people
can
batch
them
and
right
now
the
issue
is
when
you
can't
have
it
back
to
like
five,
because
you're
limited
to
what
you
can
query
out
of
a
get
table
row
request.
I
So
you
just
end
up
doing
you
know:
10
requests
for
10
different,
you
know
items
that
you
want,
which
is
a
lot
of
load
on
the
endpoints,
and
it
actually
makes
some
endpoints
that
have
aggressive
rate
limits.
You
end
up
getting
your
website
and
your
front
end
rate
limited
because
you're
doing
10
requests
and
you're
kind
of
bursting,
correct
and
then
and
then
you
you
get
failed,
endpoint
failed
request
because
you
got
rate
limited
by
the
endpoint,
because
you
had
to
do
10
requests.
You
couldn't
batch
them
type
of
thing,
so.
I
G
That
was
what
that's
what
this
change
that
triggered.
This
conversation
provides
in
three
two
is
that
you
know,
particularly
if
you're
running
a
private
node,
you
can
set
the
limit
very
high
and
then
it
it
no
longer
has
the
hard-coded
limit,
and
so
you
can
actually
get
all
the
table
rows
that
you
want.
A
I
Still
limited
in
because
that's
just
for
one
contract
and
very
limited
to
a
lower
and
upper
bounds.
Yes,
if
you
have
a
a
contract
with
ten
thousand
rows,
you
can't
do
upper
lower
bound.
So
an
example
is
the
atomic
asset
Atomic
assets,
nft
contract.
You
cannot
use
lower
and
upper
bound
because
you're
just
going
to
be
scanning
forever.
I
There's
a
lot
of
use
cases
where
what
we
have
in
features
isn't
really
enough
to
query
exactly
what
you
want.
So
it's
just
an
opportunity
to
kind
of
improve
the
the
get
table
rows.
Maybe
it's
a
new
request.
I
don't
know!
Maybe
Aaron
has
a
lot
of
ideas
on
how
to
improve
that
get
table.
Row
endpoint,
but
it
can
be
a
collaborative
effort
to
improve
that.
A
G
Think
in
that
regard
like,
if
we
wanted
to
provide
something
that
had
that
sort
of
querying
capability
in
that
sort
of
functionality,
I
I
would
think
that
we'd
want
to
go
the
route
of
of
providing
that
ability
in
a
different
in
different
executable
in
terms
of
like
yep.
Not
have
the
node
actually
doing
that,
but
you
know
offload
that
into
something
else
that
they
can
service.
That
request.
You
know
I,
think
of
like
what
we
had
in
in
2.1
or
I.
G
Don't
know
if
it
was
I
guess
it
was
never
released,
but
rhodius,
which
was
would
mirror
all
the
state
of
notice
but
provide
multi-threaded
queries,
and
it
had
a
somewhat
of
like
a
graphql
type
interface
that
you
could
use
to
to
do
those
queries
and
you
could
even
craft
wasm
if
you
had.
If
your
queries
were,
you
know
complex
enough
that
you
actually
needed
a
programming
language
to
to
get
the
data.
G
I
Yeah
I
mean
it
doesn't
need
to
be
entirely
super
Advanced.
It
could
just
be
some
really.
You
know
an
improved
key
value
store
with
a
few
fancy.
You
know
scans
get
prefix
get
keys,
get
mini
Keys.
It
might
not
need
to
be
too
fancy.
You
know
to
not
over
engineer
the
entire
thing,
but
just
a
way
to
kind
of
get
keys
out
of
the
contract.
States
would
be
a
definitely
a
benefit,
but
yeah
I
think
definitely
having
it
off
the
main
thread
for
sure
that
would
be
definitely
beneficial
for
the
operators.
F
This
was
sorry
the
sort
of
what's
the
word
of
the
desire
here
is
I'm
kind
of
restating
and
adding
one
to
what
Daniel
said
right.
So
we
want
to
improve
the
experience
for
developers
with
simpler,
more
efficient
querying
capabilities.
We
want
to
reduce
bashing
on
API
nodes
by
reducing
the
number
of
requests
that
are
required
by
developers
to
perform
common
use
cases
and
related
to
that
we'd
like
to
allow
API
nids
to
protect
themselves
with
more
sane
limits
without
breaking
those
legitimate
use
cases
right.
I
H
Another
source
of
material
on
this
is
the
API
plus
paper
that
was
written
or
released
about
a
year
ago.
The
first
proposal
in
there
was
to
establish
kind
of
a
group
to
research
how
to
optimize
these
kinds
of
apis
because
they
I
said
it
in
the
BP
chat
yesterday
like
get
table,
Rose
is
begging
to
be
hammered
like
you
do
the
query.
It
says
more
and
you're,
like
okay,
I'm
gonna,
query
for
more
because
it
didn't
give
me
everything.
H
H
I,
don't
know
it.
We
didn't
know
it
when
we
were
writing
the
API
plus
paper
and
that's
why
that
kind
of
turned
into
a
generic
proposal
to
come
up
with
a
group
to
figure
that
out.
This
kind
of
is
a
group
that
could
help
figure
that
out
but
like
something
eventually
needs
to
replace,
get
table
rows
to
solve
this
problem
and
maybe
along
the
way,
there's
some
Band-Aids
to
make
it
more
optimal.
But
it's
definitely
it's
a
Swiss
army
knife
of
an
API
endpoint
it.
H
G
A
F
Possibly
before
we
before
we
do
that
real
quick.
So
this
this
last
topic,
we
discussed
I,
think
crosses
over
lines
between
what
Stephen
is
focused
on
and
what
what
I'm
focused
on.
So,
if
we
wanted
to
sort
of
follow
up
with
a
smaller
group
to
to
further
explore
that
discussion
like
who,
who
are
the
folks
that
would
like
to
be
included
in
that.