►
From YouTube: Node Operator Roundtable - May 31st, 2023
Description
Dive into a comprehensive understanding of WAX, highlighting challenges with EOS EVM, RAM Limitations, State Management, and the role of Node Operators.
00:00:00 Introduction
00:01:08 Deploying EVM Infrastructure
00:16:45 EVM Gateways
00:19:10 EVM & RAM Limitations
00:28:56 Resource Performance & Optimization
00:35:50 Node EOS 4.0.1 Upgrade
00:38:00 Network Management
00:55:05 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
B
Yes,
thanks:
it's
a
it's
a
light
week:
I
don't
have
prepared
topics
or
anything
to
review
this
week.
So
I
want
to
go
straight
into
sort
of
an
open
floor
if
there's
any
any
urgent
issues
or
simply
topics
of
interest
that
people
would
like
to
go
into
this
week
or
in
a
future
week.
It
could
just
be
something
that
we're
not
ready
to
talk
about
now,
but
can
capture
and
and
get
our
ducks
in
a
row
to
discuss
in
a
future
session.
B
Yeah
I
can
give
kind
of
a
non-update
on
us,
which
is
that
you
know
it's
still
a
topic
of
a
discussion.
I
think
I
think
in
an
abstract
sense,
there's
interest,
but
we're
not
at
a
point
where
we're
ready
to
you
know
like
move
forward
with
asking
for
people
to
do
that
so
or
or
really
for
that
matter,
having
all
the
materials
ready.
That
would
that
would
make
it
easy
for
you
to
do
so.
C
I
think
the
material
the
material
is
already
there
like
I
kind
of
looked
at
it.
It's
pretty
like
straightforward,
like
we
said
it's
just
proxy
different
segments
of
rpcs
that
respond
to
certain
queries,
it's
more
about
like
I,
think
what
Matthew
is
at
the
time
like
how
what
is
the
incentive
for
them
to
run
it,
and
what
part
is
the
one
that
actually
needs
running
and
some
of
the
I
guess
issues
I
foresee
with
it?
E
But
then
I
guess
one
more
thing
to
add
to
this.
One
is
more
like
what
is
the
role
of
enf
as
operator
and
then
the
BP
is
operator.
So
let's
say
if
a
BP
wants
to
operate
as
in
the
Eos
CVM
node,
but
there
is
no
transactions
getting
relayed
to
their
operation.
Then
they're
never
going
to
get
any
rewards.
So
maybe
there
is
sort
of
a
role
where
enf
can
play
as
the
load
balancer
for
all
the
BP
operators.
And
then
the
operator
is
just
operates,
as
you
know,
one
or
many
nodes.
E
C
Yeah
there
has
to
be
one
if
you
want
a
good,
have
a
good
user
experience,
because
people
try,
you
know,
like
I,
was
seeing
some
people
commenting
like
oh
I,
tried
to
push
my
contract
here
and,
like
the
answer
is:
oh
just
try
this
other
endpoint
and
remove
delete
from
Mecha
mask
you're
old.
You
know
this
is
obviously
not
a
good
user
experience.
C
You
want
to
have
like
a
unified
proxy
that
is
sitting
at
enf
or
supported
by
enf
and
then
some
type
of
status
or
like
checking
system
against
all
the
other
providers
that
sit
behind
this
proxy
to
decide
who
stays
in
the
proxy
as
well
as
how
to
rotate
that
proxy
yeah.
Then
they
get
to
that
proxy
there's
already.
The
Json
RPC
is
already
itself
another
proxy,
so
it
depends
where
you
actually
want
to
proxy
out
to
the
API.
C
Do
you
want
to
proxy
out
that,
like
you
know,
the
main
kind
of
endpoint
or
you
want
to
proxy
out,
only
see
the
TX
wrapper
transactions
or
the
one
that
requires
a
ship
like
the
the
actual
kind
of
node
itself?
All
these
will
have
different
costs
for
the
for
the
API
provider,
as
well
as
different,
like
abilities
or
ways
to
you
know.
Do
this.
F
B
So,
hang
on
backing
up,
yes,
I'll
I'll,
get
to
that
and
sorry
backing
up.
The
broader
focus
is
just
open
floor,
Shack
race.
This
is
something
of
interest
and
yeah,
but
the
question
broadly
is
is:
is
there
interest
in
EOS
block
producers
running
es
evm
nodes
in
the
future
and
then
questions
around
decentralization
incentives?
F
What
I
mean
by
that
is
we're
currently
doing
it,
but
we
are
working
towards
being
able
to
identify
a
stakeholder
that
would
take
this
on
so
think
of,
for
example,
partnering
with
inferior
or
partnering
with
Alchemy,
and
so
it's
a
very
centralized
approach
to
providing
the
RBC
note.
We've
seen
that
that's
is
what
is
successful
in
other
ecosystems,
the
users
are
comfortable
with
that.
There's
an
SLA
you
deal
with
one
and
the
uptime
is,
is
quite
high
and
it's
more
performant.
F
We
will,
as
the
enf
provide
kind
of
an
MVP
documentation,
slash
how
to
so
that
if
people
want
to
run
their
own
EVMS
for
testing
purposes
or
for
whatever
it
is,
they
want
to
run
their
own
evm
RPC
nodes.
They
will
be
able
to
do
so
with
documentation.
We
provide,
but
we're
not
going
down
that
path
of
enabling
that
so
much
as
in
deploying
a
lot
of
resources
to
ensure
that
the
rpcs
are
load
balanced
and
that
hey
we
point
to
all
these
different
ones.
It's
the
opposite.
F
C
F
We
if
we
appoint
infuro,
for
example,
no,
so
nobody
stops
anybody
from
from
doing
it
if
they
want.
But
let's
say
are
the
end
point
that
we
point
to
that.
That
enf
says
please
point
to
this
is
run
by
infuro,
how
they
do
that
is
on
their
end.
But
the
idea
is
not
it's
going
to
be
we're
not
going
to
incentivize
here's
the
inferior
API
endpoint,
here's,
the
other
BP
API.
C
You
know
having
different
endpoints
is
just
bad
user
experience.
Now
the
idea
was
always
one
endpoint,
like
we
discussed
in
a
previous
call.
How
is
that
one
endpoint
that
will
be
say,
enf
controlled
and
then
that
could
have
its
own
health
checks
against
other
decentralized
endpoints,
and
it
manages
the
proxy
but
I
understand
now,
at
least
like
the
actual
of
that.
A
F
To
create
this,
this
framework
of
let's
say
decentralized
nodes
is
extremely.
You
know:
labor
intensive
in
terms
of
deployment
of
resources,
so
not
just
Financial
but
actual
people.
Creating
this
setting
this
up
having
the
the
marketing
alongside
this,
so
that
people
will
know
where
to
go
is
is
you
know
we
don't
have
the
ability
to
do
both?
Basically,
we
can't
create
a
partnership
with
something
like
inferior,
while
also
creating
a
framework
around
having
it
decentralizing
and
supporting
that
leveraging
that
we're
choosing
that
route.
C
F
A
F
And
we've
seen
that
happen
through
dapps,
where
they've
got
a
particular
application.
They've
got
a
particular
service.
They
want
to
ensure
that
the
uptime
to
access
their
particular
application
is,
is
in
a
way
controlled
by
them,
so
they
also
offer
an
RPC
endpoint
and
then
to
those
users.
That
is
the
choice
that
that
they
make,
and
so
obviously
anybody
can
do
whatever
they
want.
C
F
C
You
guys
could
we're
asking
also
in
the
last
call
what
do
you
see
as
the
vision
or
they
were
asking
like
us
in
general,
or
people,
readers
or
people
involved?
What's
the
vision
of
EOS
evm?
Is
it
to,
for
example,
make
it
like
an
easy
path
for
existing
ethereum
users
or
ebm
users
to
come
and
get
a
benefit
right
away
of?
You
know
what
adslope
has
to
offer
in
terms
of
Cheaper
resources
and
everything
else,
and
then
slowly
try
to
once
they
reach
certain
limits
or
inefficiencies
within
your
CBM.
C
F
F
F
If
you
go
through
evm
and
that
applies
I
think
to
a
particular
subset
of
developers
that
are
either
running
on
ethereum
or
they're
running
on
EDM
compatible
chains,
so
for
them
is
giving
access
to
EOS
as
the
engine
through,
let's
say,
evm
the
SDK,
so
the
world
that
they're
aware
of
let's
say
the
the
card
chassis
that
they're
coming
in
the
doors
the
window,
the
steering
wheel,
everything
all
familiar
to
them.
The
engine
now
is
else
in
the
background.
F
I
would
say
less
so
the
second
part
of
what
you
said,
which
is
then
but
the
real
ideas
and
then
to
get
them
to
just
build
all
on
the
EOS
I
think
in
parallel
to
what's
happening
with
the
evm
native
development
usability
is
still
you
know.
It's
still
underway,
people
are
still
building
this
we're
still
building
this,
but
to
catch
up
to
this
idea
of
the
chassis
kind
of
the
window,
too,
of
what
evm
world
has
created.
It's
going
to
take
a
really
long
time
time.
F
So
the
idea
is
not
in
a
very
short
period
of
time,
get
people
to
start
leveraging
native
EOS.
It's
going
to
be
to
continue
using
pvm,
while
in
the
meantime
EOS
as
a
as
a
you
know,
native
stack
does
build
those
extra
libraries
and
all
those
functions
Etc,
but
that's
got
I
mean
took,
took
I,
guess
if
they're
on
seven
years
to
get
to
where
they
are
today
with
all
the
capital
they
had
with
with
all
the
history.
F
So
it
will
take
us
quite
some
time
to
be
able
to
replicate
that
that's
not
happening
anytime
soon,
so
they're
completely
separate
I
would
say.
The
focus
is
to
get
people
to
come
into
the
evm
because
it
abstracts
away
a
lot
of
the
difficulties
of
blockchain,
and
so
they
can
just
again.
I
will
run
them
yeah
it's
just.
Basically
they
can
get
up
and
running
very
very
quickly.
One
of
the
big
things
we've
heard
a
lot
is
people
saying
you
know
there
are
libraries
out
there
they're
already
audited.
They
come
on
the
native
side.
F
They're
like
oh
I,
need
to
build
my
own
Road
I
need
to
build
my
own.
You
know,
basically,
the
own
streets
build
everything
from
scratch
and
I've
got
very
little
support.
Well,
now,
you're
able
to
just
fast
forward
all
of
that
come
through
this
space
at
a
much
lower
cost,
even
auditing
costs
Etc.
So
just
the
the
from
zero
to
one
is
much
much
faster
on
this
side.
F
At
the
same
time,
though,
for
those
who
require
the
fine
tuning
which
I'm
not
convinced,
is
many
people
right
now,
they
would
keep
going
on
the
you
know,
native
from
the
beginning
side,
and
there
are
already
applications
running
on
this
and
there's
some
that
will
justify
doing
that,
and
there
are
others
that
will
justify
I
just
want
to
skip
the
line.
This
is
good
enough
for
what
I'm
looking
for
and
we're
just
encouraging
you
to
come
through
this
door.
C
F
Trails
yeah
and
the
more
usage,
so
what
we've
seen
as
well
is
within
a
short
period
of
time,
the
usage
of
EOS
native
in
terms
of
tokens
that
is
locking
up
or
I
guess.
Financial
metrics
is
almost
a
one
for
one
with
evm
already
very
early
on,
so
the
amount
of
EOS
tokens
that
are
being
locked
up
within
the
the
evm
smart
contract
are
almost
one
for
one.
F
If
you
can,
you
know
if
you,
if
you
make
some
some
comparisons
to
the
amount
that
is
locked
up
in
Rex,
let's
sound
a
daily
basis,
because
it's
so
much
easier
on
this
side,
and
the
idea
is
that
the
more
people
come
through
this
door,
the
more
EOS
is
it's
going
to
lock
up
one
of
them.
Is
it
it's
locked
up
and
then
it's
distributed
to
users
that
do
certain
actions,
the
other
one?
Is
it's
locked
up
and
it's
taken
out
of
circulation,
so
everybody
gets
to
benefit
from.
F
C
F
F
You
know
where
you're
in
a
way
Gateway
like
a
a
filter
to
help
people
choose
where
to
deploy
or
how
to
deploy.
Etc
I
would
say
that
sending
people
the
evm
route
has
a
much
lower
cost
if
they're.
If
you
know
that
is
that
is
a
factor
and
the
amount
of
capital
that's
available
on
both
sides
just
goes
far
longer
on
the
evm
than
on
Native,
because
a
lot
of
the
costs
can
be
abstracted
away.
So
we
see
from
even
let's
say,
a
grant
framework
perspectives.
F
The
grant
size
requests
for
people
coming
through
the
evm
is
much
lower
than
on
the
native
side,
and
so
we're
able
to
effectively
give
out.
You
know
more
to
more
different
teams
than
we
are
on
on
the
evm
side,
and
then
those
teams
are
able
to
deploy
quicker
and
come
to
Market
much
much
much
much
much
faster
than
on
the
native
side,
so
as
node
operators
I
think
that
is
an
opportunity,
for
you,
guys
is
if
people
are
reaching
out
and
saying
I
want
to
deploy
any
else.
I
want
whatever
XYZ.
F
Here
is
what
I'm
trying
to
build
actually
sending
them
through
the
evm
way.
It
might
be
the
the
better
case
for
some,
because
their
cost
will
be
lower
time
to
deploy
and
will
be
faster
and
er
still
benefits
in
the
end
depending
and
what
their
requirements
are.
So
if
they're,
you
know,
if
you
deem
that
the
requirements-
okay,
you
need
to
build
on
Native.
Here's
why
you
give
them
that
option
depending
on
if
they
already
have
Community
or
what
their
requirements
are
sending
into
evm
is,
is
a
pretty
good
solution
too
either
way.
F
I
mean
that
applies
as
well
to
Native.
So,
yes,
it's
just
different
kind
of
work.
Yes,
one
of
them,
though,
is
a
catch
up,
and
it's
it's
a
little
bit
more
within
our
control
versus
native.
Yes,
it
is
our
on
our
control
board,
we're
talking
about
much
longer
timelines
and
a
lot
of
it
is
not
under
our
control.
C
My
concern
is
this:
it's
actually
very
successful,
I
think
that's
when
the
problems
come
like
you
know,
like
there's
a
big
problem.
Well,
the
first
problem
I
raised
right
like
the
ram
issue
like
I,
don't
see
that
being
addressed
in
the
ucbm
but
currency.
It's
the
contract
that
pays
for
the
RAM
and
in
turn
raises
the
price
for
all
users,
because
it
just
adjusts
the
gas
value
in
the
global
table
of
the
ucbn
contract.
C
So,
like
once,
people
use
it
and
then
once
people
find
out
about
this,
so
they
might
just
use
it
and
create
like
a
million
contract
like
I'm,
not
aware,
there's
any
limitations
now
other
than
the
contract.
Only
the
RAM
and
can
you
know
unilaterally,
decide
to
delete
or
free
up
Ram,
but
that
also,
obviously,
as
you
know,
has
consequences.
C
If
people
have
things
attached
to
it,
and
so
that
part
I,
don't
know
like
how
that
might
be
handled
down
the
line,
as
well
as
putting
limitations,
as
we
mentioned
in
the
smart
contract
to
enforce
that
gas
fee
right.
So
the
TX
wrapper
node
doesn't
just
say,
I'm
going
to
charge
100x
and
have
users
like
you
know,
get
screwed
over
by
a
bad.
You
know
operator,
for
example,.
F
All
good
points,
those
are
things
that
I
think
whether
or
not
they
will
be
addressed,
or
what
the
what
the
I
guess
direction
is.
There
will
be
determined
over
time
in
a
way
right
now.
There
are
base
level
problems
that
are
I
guess
higher
in
priority
to
address
versus
the
at
some
point,
we're
going
to
have
millions
of
users
if
we
get
to
millions
of
users
and
we've
got
so
much
RAM
usage
Etc,
that's
a
in
a
way
it's
one
of
the
good
problems
you
to
have.
C
Priority
yeah
I,
don't
think
it's
the
fact
that
in
the
short
term,
like
I
said
but
yeah
like
so,
the
focus
is
more
gonna,
be
on
the
whole
point
of
it
really
the
the
short-term
point,
at
least
or
even
the
long
term,
which
is
like
the
onboard
users.
So
I
I
got
it
a
majority
of
the
workers
to
make
sure
everything
is
super.
Smooth
super
reliable
and
you
know,
probably
more
tooling,
in
terms
of
user
experience,
for
people
to
bridge
to
do
this,
and
so
for
sure.
We.
F
Definitely
have
the
opposite
problem
in
EOS
compared
to
other
chains,
where
we
have
way
more
Supply
than
there
is
I
mean
I.
Think
that
applies
to
a
lot
of
blockchains,
but
the
engine
that
we
have
at
the
base
is
extremely
powerful.
We've
got
plenty
of
time
before
we're
stressing
out
that
that
that
engine
and
so
right
now
the
focus
is
on
getting
people
to
use
that
engine
not
trying
to
optimize
that
and
engine
further
to
even
ever
increase
the
supply.
Without
ever
attempting
to
address
the
man.
F
Then
it
becomes
kind
of
a
pendulum
of
you
need
to
be
able
to
grow
sustainably,
but
you
can't
provide
too
much
Supply
without
letting
the
demand
come
in,
because
that's
what
we've
had
historically
just
very
little
Demand
with
Unlimited
Supply
and
then
when
the
demand
came
in
the
reaction
was
no
no,
let's
stop
everything
which
is
kind
of
what
edos
did
and
then,
ultimately,
what
that
did
is
it.
It
lost
a
business
opportunity
that
went
elsewhere,
which
actually
created
a
lot
of
value
elsewhere,
whether
or
not
it
was
value
for
everybody.
F
F
Yeah,
yeah,
of
course,
of
course,
and
so
I
like,
for
example,
is
Yama
I,
don't
know
if
Yom
is
on
this
call
Shaq,
but
we've
been
talking
about
the
the
resource
in
general
right,
because
the
ux
has
a
completely
different
resource
model
and
it's
essentially
learned
from
EOS
and
made
things
completely
differently.
Whether
or
not
EOS
goes
in
that
direction
in
the
future
or
how
we
potentially
bring
back
up
the
topic
of
of
RAM
and
RAM
output.
F
A
lot
of
that
I
think
is
also
up
to
the
BP's
their
role
within
this,
and
so
a
few
people
have
reached
out
to
the
NF
about
Ram
in
particular
and
what
they
see
as
a
you
know.
What
are
we
doing
now,
but
what
are
we
doing
in
the
future?
How
we
know
it's
going
to
be
an
issue
in
the
future?
How
are
we
going
to
handle
that
or
where
which
direction
we're
going?
That
is
a
discussion.
I
think
that's
important
for
the
the
BPS
to
have
that's
less
on
the
ens.
F
In
particular
and
the
benefit
to
Performance,
yes,
Michael
the
benefit
to
Performance
versus,
let's
say
new
Xeon
right
now
that
has
more
cores
that
are
being
unused,
but
then
it
has
ECC
memory.
Is
that
a
direction
we
want
to
incentivize
in
the
future,
because
we
see
that
it
is
potentially
causing
problems,
but
it's
not
right
now,
because
there
are
other
problems
before
that
that
are
likely
issues
before
we
even
get
to
that
being.
But
those
I
think
are
the
discussions
that
the
BPS
can
have
in
terms
of
right.
F
Now,
we've
got
the
luxury
of
having
in
a
way
way
more
Supply
than
demand.
That,
ideally
won't
be
the
case
forever.
Where
are
potential
optimizations
that
we
would
want
to
focus
on
in
the
future?
That's
a
discussion
entirely.
I
think
that
this
group
would
be
well
suited
to
to
have
and
then
to
propose
something
and
Champion
a
particular
direction,
leveraging
the
work
that
other
chains,
for
example,
ux
in
this
particular
is
for
for
resources,
have
gone
down.
F
F
If
at
least
your
nose
are
running
a
hundred
percent
of
the
time
that
is
the
you
know,
the
most
important
job
that
that
you
can
do
in
the
network
is
ensure
that
Network
reliability,
that
Network
stability,
because
that's
something
that
very
few
networks
are
able
to
claim,
especially
the
ones
that
we're
competing
against
the
ones
that
you
know
very
highly
scalable
low
cost
performance
yeah.
This
is
something
that
EOS
just
trumps.
Everybody
over
I
mean
there's.
There's
no
competition
out
there
like
like
Yasser,
like
antelope,
basically
at
the
base
I.
D
B
B
D
It's
it's.
What
results
as
the
massive
State
database
and
yeah?
It
was
even
I.
Think
a
topic
about
the
pruning
or
more
efficient
use
of
like
does
wax
need
a
95
gig
database
smashed
into
RAM,
but
anyway,
yeah
so
the
whole
Rabbit
Hole
of
performance
and
optimizations
and
i9's
outrunning
all
the
rest
of
them
and
causing
this
massive
disparage
between
the
xeons
that
are
validating
versus
the
iodine
hot
rods.
D
C
D
Well,
I
mean
even
just
the
building
side
of
it.
You
know
people
have
nice
high,
end
or
xeons
signing
it.
Two.
You
know
two
tenths
of
a
second
and
then
you
bring
in
these
I'm
waiting
for
the
14th
gen
i9's
to
drop
so
I
could
see
all
right.
How
fast
can
you
really
rip
a
calculation
and
I
I
bet
you
it's
going
to
be
a
third
of
the
speed,
so
you
really
get
even
acceptable
good,
decent
Hardware.
You
can
get
a
pretty
broad
range
anyway,.
C
So
on
the
effects
buildings
like
and
they're
still
able
to
verify
the
other,
BPS
and
whatnot.
Then
people
will
you
know
once
you
get
more
reduction
and
people
have
like
heavy
things
run
like
say
proofs
or
any
of
this
stuff
they're
gonna
time
it
like
I,
was
doing
with
cashing
up
with
proof
when
it's
you
know,
searching
BTS
in
certain
chains,
which
there
was
a
big
disparity
between
their
performance,
so
that
I
pay
less
in
resource
costs.
D
D
Got
thread
performance
yeah,
the
the
i9s
you
know
are
what
I
try
to
describe
to
folks.
I
mean
they're
they're,
a
desktop.
You
know
non-sherver
class
proc,
but
they're
designed
for
like
gaming
machines,
which
need
just
a
few
cores,
but
really
as
fast
as
you
can
possibly
get
them
versus
a
Xeon
which
has
you
know,
64
different
cores
and
node
OS
is
single
threaded
on
you
know
it's
most
critical
applications,
although
that's
getting
better.
What
that
also
results
in
the
I9.
Technically,
the
chipset
only
really
supports
it
to
128
gigs
of
RAM.
D
Now,
supposedly
you
can
go
higher,
I
think
some
people
say
102,
but
I
mean
you
really
got
to
push
it
and
go
outside
of
the
specs,
and
here
we
are
running
nodes
that
on
Booth
mirror
minimum
really
required
95
gigs
worth
of
RAM,
and
it
ain't
getting
much
smaller,
so
you're
going
to
surpass
the
amount
of
physical
memory
that
a
whole
tier
of
it
ain't.
Just
I9
I
mean
there's
a
lot
of
xeons.
Well,.
F
D
F
Fast
single
cook,
but
then
we're
also
seeing
that
catch
up
right
so
depending
on
which
ionized
people
are
running
if
they're
running
them
at
five
gigahertz
for
single
core.
Well,
now
you
get
4.5
gigahertz
Xeon.
So
then
the
Delta
is
pretty
small,
but
one
you
can
accommodate
more
RAM
and
it's
ECC
Ram.
So
like
it's,
a
game
of
cat
Mouse
continue
what.
D
That
happens
with
that
is
that
you
go
to
the
14th
gen
i9s,
we'll
call
it,
and
what
now
ends
up
happening
is
that
that
is
signing
blocks.
I
mean
Moore's
Law,
oh,
it
just
destroys.
The
the
mathematics
is
that
my
i9s,
which
are
only
a
year
and
a
half
old,
will
be
signing
it
four
times.
Probably
is
a
lot
of
ways
as
these
14th
gen.
So
you
address
one
issue.
C
D
You're
talking
about
just
the
DDR
that
on
chain
where's,
Aaron
Aaron's,
always
The
Advocate,
that
said
yeah,
that's
not
really.
Ddr
ddr5
doesn't
truly
have
a
ECC
on
chip
like
they
they
touted
for,
but
it
is
getting
better,
but
Kevin
can
attest.
Man
I
have
seen
crazy,
weird
issues
with
these
i9s
and
non-ecc.
F
And
but
it
is
ECC,
that's
the
thing
is,
it
might
be
something
prior
to
even
it
ECC
being
relevant,
because
there
are
other
issues
with
software
with
Hardware
in
general
or
relays,
for
example,
they're
just
not
as
strong,
so
it
gets
dropped
not
because
or
there's
an
issue,
maybe
not
even
because
of
ECC.
Yet.
D
D
Yes,
so,
but
it
does
I
I
forget
about
push
things
so
hard
because
I
run
so
much
but
nah,
not
even
the
it
ain't
an
internet
connection
over
it
truly
is
holy
chain.
Bass
came
back
with
something
completely
different
than
what
it
expected
I.
Your
memory
is
why
and
it
just
tumbled
over
itself
and
whatever
but
sorry
Brian,
to
explain
why
the
i9s
kind
of
get
called
out
they're
the
fastest
single
thread
you
can
get,
but
they
have
their
inherent
limitations
in
compared
to
true
server,
Enterprise
class
server.
B
C
G
Why
so,
maybe
you
should
pray
for
that?
I
mean
we
certainly
hope
so.
Certainly
let
us
know
if
not
and
we'll
we'll
get
up
we're,
not
drill
two
out.
If
we,
if
need
be
right,
so
yeah
I
mean
4.0
is
certainly
where
we
want
people
to
be
at
moving
forward.
You
know,
as
soon
as
you
can
please
do
upgrade
from
your
3.2
stack
to
your
4.0
stack,
there's
a
lot
of
cool
new
stuff
in
there.
Hopefully
you
take
advantage
of
it
and
give
us
feedback.
G
A
B
Like
as
an
example,
you
know
if
we
go
in
the
direction
of
some
kind
of
state
sharding.
You
know
that
is
sort
of
that's
the
word
I'm
looking
for
that
is
incompatible
with
some
things
that
would
be
really
effective,
optimizations
with
how
it
works
today,
right
so,
but
so
so
it's
not
something
where
there's
just
like
an
obvious
approach
and
that's
why
we
we
aren't,
you
know,
there's
still
a
lot
of
active
discussion,
but
we
will
definitely.
D
Well,
like
say,
I
mean
wax
tended
to
bring
it
to
light.
Just
because
it
kind
of
took
off
and
I
mean
there
was
the
you
know,
run
on
accounts,
and
but
it
sounds
like
I
mean
even
contracts
itself.
You
know
really
kind
of
caused
it
and
being
involved
with
so
many
other
chains
that
that
utilize,
the
technology
either
publicly
or
privately,
even
ones
that
are
talking
about.
Oh
we're
going
to
get
millions
and
millions
of
accounts,
you
know
and
and
right
at
well.
D
A
D
C
D
C
But
essentially,
what
you
got
to
decide
to
decide
to
build
for
the
future
or
to
decide
to
vote,
for
you
know
the
problems
that
happen
in
the
past
right,
because
there's
different
solution,
if
we're
trying
to
you,
know,
spend
a
lot
of
energy
into
worrying
about.
You
know
like
some
additional
street
optimizations
that
that
would
really
take
away
from
maybe
other
improvements
that
will
benefit
change,
that
didn't
necessarily
run
into
this
issue
and
have
ways
to
mitigate
that
issue
in
the
future.
It
might
not
be
the
best
focus
on
time
like
in
general,.
D
Totally
opened
ever,
you
know,
I
know
they're,
bigger
fish
to
fry
I.
Just
that
was
a
question
that,
with
no
other
topics
presented,
I
was
curious,
Lauren
because
of
those
reasons
yes
painful
on
wax
and
it,
but
it's
not
only
just
the
wax
in
the
current
state,
as
I
mentioned
this
to
some
of
the
other
chains.
C
No
I
mean
to
accomplish
actually
like
say
making
some
big
optimization
to
the
state
where
it's
moving
to
shards,
as
you
were
saying
that
that
you
know
will
have
to
be
loaded
in
and
out
of
RAM,
and
you
know
things
of
the
sort.
This
is
you're
going
to
make
compromises
that
not
everybody
will
be
happy
with,
depending
on
their
use
case,
and
it
doesn't
and
there's
I
think
better.
Solutions.
C
Item
yeah
I,
don't
mean
to
like
hold
that
word
like
or
delete
it,
but
my
point
is
any
work
on
that
part
is
very
high
level
work.
It's.
It
takes
a
lot
of
time,
energy
and
testing,
and
it's
just
talking
about
like
really
the
opportunity
cost
of
what
could
be
done
instead
of
that,
and
then
we
can
compare.
For
example,.
D
Correct
I
definitely
have
some
there's
some
Creative
Solutions
to
it.
I
guess.
My
point
is:
is
that
there
are
going
to
be
several
projects
that
are
going
to
stumble
exactly
into
what
wax
learned,
because
that
layer,
one
does
have
some
inherent
works,
and
you
need
to
probably
think
about
it
from
a
layer
two,
but
that
was
really
where
it
came
from.
Is
that
it's
it's
very
heavy
on
RAM
and
I
mean
for
the
same
argument.
G
D
Don't
need
much
less
wax,
I
mean
so
you're
right.
Definitely
not
I'd,
rather
I'd
love
to
see
instant
finality
long
before
I
see
a
Toyota
State.
We
can
keep
throwing
Hardware
at
it.
But
it's
not
to
say
I
mean
that's,
that's
definitely
there
and
a
lot
of
the
people
that
are
utilizing
the
technology.
Don't
really
see
that
and
I
think
we'll
do
exactly
like.
B
Yeah,
given
limited
time
and
resources,
it
becomes
an
exercise
and
theory
of
constraints.
Right,
like
there's
only
one
one
action,
that's
going
to
remove
a
limitation
and
increase
you
know
whatever
metric.
It
is
that
you
you're
considering
most
important
right.
So
you
know
ability
to
scale
state
will
will
become
that
thing.
G
Well,
I
think
Shaq
makes
a
lot
of
good
points
there
right
I
mean
it's.
The
typical
computer
science
trade-off
between
you
know
memory
and
performance.
Like
you
know,
we've
discussed
in
the
past
things
like
ability
to
to
get
some
multi-threaded
capability.
One
way
of
doing
that
is
to
effectively
double
your
RAM
requirement.
Where
you,
you
know,
effectively
make
a
copy
of
your
entire
Ram
that
you
can.
You
can
use
while
you're
updating
the
other
Ram.
Now
you
know
out
of
the
gate
that
doubles
your
RAM
requirement.
You
know
for
a
chain
like
Wax.
G
Where
do
you
head
and
what
sort
of
features
are
you
looking
at
I
mean
that's
sad
I
mean
there
is
work,
a
foot
to
look
at
reducing
random
requirements,
and
you
know
I
anticipate
that
that
will
you
know
that
will
bear
some
sort
of
fruit
at
this
point,
we'll
see
where
that
heads
and
what
it
what
it
realizes
into,
but
yeah
there's
always
going
to
be
the
trade-off
there
in
terms
of
like.
Where
do
we
want
to
head
with
performance?
G
G
There's
ways:
I
think
that
we
can
mitigate
the
infat
by
looking
at
a
layer
of
usage
of
ram,
whether
you
know
it's
hot
or
code
or
or
those
sorts
of
things
in
terms
of
of
layering,
that
up
and
and
you
know,
hopefully
try
to
get
the
a
little
bit
of
the
best
of
the
Both
Worlds
or
at
least
trade-offs
in
both
directions.
To
get
you,
you
know
where
we
would
like
to
be
eventually
foreign.
C
Transactions
there
will
be
open
all
those
doors,
especially
if
you
know
at
the
time
also
we
get
combined
some
work
on
instead
of
get
act,
you
know
like
they
get
return
value,
but
having
a
composability
so
like
the
smart
contracts
can
build
on
top
of
each
other.
That's
another
feature
that
I
personally
be
looking
forward
to
more
than
potentially
some
State
improvements,
but
you
know,
as
I
said,
you
can
never,
please
everybody.
G
Yeah
the
the
ability
to
compose
things
up
I,
you
know
that's
another
area,
but
you
know
we're
looking
at
I'm,
also
kind
of
excited
about
that.
The
new
read-only
transaction
capability
is
a
bit
of
that.
I
know
that
I
know
you're
actually
talking
about
something
a
little
different
there,
but
the
the
read-only
transaction
does
allow
you
to
like
provide
a
query
capability
that
allows
you
to
compose
across
various
tables
and
get
that
into
a
form.
C
Well
also,
try
and
win
get
action
or
like
get
returned
value
when
you're
returning
your
value,
you
now
like
a
lot
of
times.
Do
we
need
a
back-end?
You
can
just
like
clearly
have
some
logic
there
that
will,
you
know,
give
you
the
metrics
you
need,
and
as
long
as
you
don't
need
history
you're
having
the
chain
do
that
for
you
and
you're
able
to
process
that,
like
in
parallel,
it's
dismute.
G
Yeah
any
feedback
there
that
you
guys
hear
about
or
run
into
yourselves
in
terms
of
the
new
read-only
transaction
capability
group
I
mean
we'd
love
to
hear
as
well.
You
know
we
we
think
that
provides
some
very
useful
functionality
that
people
will
find
beneficial,
but
certainly
any
feedback.
There
is
more
than
welcome.
B
D
G
D
G
We
did
make
some
changes
in
that
arena
in
4.0
in
terms
of
the
way
that's
done
and
so
yeah
I
could
I
could
definitely
see
that
being
being
addressed
as
kind
of
a
an
art
artifact
of
doing
some
other
work
that
we
were
doing
there
but
yeah
yeah.
Let
me
take
a
look
at
that.
I
kind
of
I
had
not
had
said
to
the
side
and
hadn't
got
back
to
it,
but
yeah.
Let
me
take
a
look
and
see
if
anything
jumps
out
at
me.