►
From YouTube: Node Operator Roundtable - June 28, 2023
Description
This week, the EOS Node Operator Roundtable discusses Leap 5.0 candidates, Corrupted Block Logs recovery, Reducing Node Operator costs, Upgrading to Leap 4.0, OC feature, and more!
00:00:00 Start
00:00:09 Reworking Leap 5.0
00:03:36 Block Logs
00:13:53 Block LOG Trimming
00:25:31 Corrupted Block Logs
00:27:55 Reducing Node Operator Costs
00:30:08 Upgrading to Leap 4.0
00:39:59 Preparing for Consensus Upgrades
00:00:00 Enabling OC Features
00:57:51 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
That
that
need
to
happen
sooner
rather
than
later
about
sort
of
the
process
for
making
you
know,
consensus
upgrades
occur
because
what
will
what
we
do
know
for
sure
about
5.0
is
that
it
will
include
at
least
one
consensus
protocol
feature
upgrade
and
yeah.
So
that's
coming
soon
stay
tuned
with
that
I.
B
Don't
have
a
set
agenda
for
today,
so
we're
gonna
go
open
floor
and
hear
out
people's
topics
of
interest,
and
then,
after
a
few
minutes
of
that,
we
will
choose
one
to
dive
into
Michael.
I'm
gonna
call
on
you
because
it
sounded
like
you
already
had
one
of
of
interest
that
you
might
want
to
talk
about.
D
I
I
have
a
topic
we've
been
discussing,
but
that
was
more
kind
of
a
joke.
I
am
curious,
I
know
we're
still
kind
of
fighting
some
of
the
I,
don't
want
to
say
core
issues
with
full
war,
and
you
know
some
of
the
major
overalls
and
just
some
of
the
quirks
that
are
still
being
worked
out.
I
think
for
a
three.
D
D
You
had
this
we're
still
fixing
some
of
the
cores
in
four,
but
really
it's
happened
to
get
cross-applied
five
and
then
they're
kind
of
becomes
this
dual
Line
in
the
Sand
to
be
like,
oh
yeah,
so
I
don't
know
it
just
gets
it's
great
to
see
the
progress,
but
it's
almost
like
it's
damn.
We
haven't
even
finished.
C
B
D
D
I
ended
up
having
to
use
esire,
lock
log
tool
or
the
original
one
ESI
log,
you
know
the
old
one,
and
that
worked
and
I
took
some
I
took
some
screenshots
and
I'm.
If
you
let
me
share
screen
I'll,
just
show
you
what
the
difference
is,
if
you,
if
you
want
to
see
it
otherwise,
I'd
be
good
share.
Screen.
D
D
D
D
D
D
D
Time
guys
it
was
this
was
I,
mean
my
idea,
like
the
user.
Experience
of
the
syntax
I
want
to
keep
basically
everything.
Okay,
so
you
might
be
right.
I
didn't
try
that,
but
what
it
does
say
you
know,
but
the
first
block
in
the
log
is
one
so
I
I
mean
okay,
two
may
work,
but
one
it
always
stalked.
There
was
a
block
one
in
there
from
yeah
yeah.
D
D
D
It
dogs
at
the
disc,
look
I
saved
you
a
few
of
these,
but
yeah
that
I
haven't
even
had
to
run
into
that,
but
that
that's?
What
is
why
we're
so
I
I
am
so
scared
I
run
into
that
a
lot
because
I
don't
run
ECC
because
I
run
I9
rig,
so
my
host
will
just
clip
out
more
frequently.
This
is
this.
Is
ECC,
this
is
an
ECC
correct,
I
mean
that's,
why
you
only
notice
it
when
it
Powers
off,
but
for
the
sake
of
the
argument,
it's
not
just
a
power
off.
D
If,
if
and
it's
got
to
be,
Memory
related,
that's
what
everybody
keeps
telling
me,
but
if
it
hits
a
bad
block
and
it
basically
crushes
my
whole
Ubuntu,
node
and
well.
Ultimately,
there
were
nine
State
history,
instances
that
every
single
one
of
them
had
to
do.
This
exact
same
thing
and
I
did
relay
and.
C
The
concern
okay
and
like
is
that
is
the
goons,
for
example,
to
or
to
do
a
smoke
test
or
node
EOS,
launch
and
then
grab
say
last
block
that
is
working
or
at
least
what's
reported
by
the
tool
and
then
go
back.
I,
don't
know
whatever
number
of
blocks
before
it.
And
that
way
you
can
start
new
EOS
with
like
an
Auto
Trim
option
and
you
specify
how
many
blocks
behind
and
that
way
to
server
restarts
and
automatically,
like
you
upload
your
style
as
a
service.
Then
Theory
back
to.
D
D
Could
be
longer
likes
to
break
things
and
apparently
I
never
break
it.
This
way,
I
never
have
this
problem.
You
guys
are
always
so
I
had
wrong.
Roll
back
and
I
never
need
to
robot
good
tune,
went
off
just
go
and
pull
the
plugs.
Trust
me.
Our
data
center
provider
has
been
very
good
at
just
randomly
turning
off
machines.
So
let
me
let
me
let
me
log
into
your
nodes.
I'll
take
care
of
it.
D
Do
you
use
snapshots
yeah,
but
but
I'm
using
ZFS,
all
the
block
songs
are
on
ZFS,
so
VFS
is
protecting
me
yeah,
the
safety
of
FS,
your
Associates,
myself,
I,
don't
know
I
I,
say
it's
their
defense.
Okay!
Is
that
the
first
I
suppose
I
still
lighter
file
system.
Kangaroo,
ZFS
I
should
say
that
too,
but
I
think
Canada.
A
C
D
So
so
it's
kind
of
twofold
I
mean
number
one,
and
we
were
just
kind
of
generally
chatting
about
this
I
think
in
some
discussion
about
kind
of
normal
error,
handlings
for
node
operators
and
trust
me.
Regular
node
operators
shut
that
down
in
properly
way
more
than
Matthew
guns.
I
promise
that,
but
it
was
really
kind
of
hey.
If
it
could
error
handle
this.
D
B
B
So
what
I
want
to
do
now
is
like
try
to
distill
the
problems
in
explain
it
like
I'm
five
sort
of
language
here,
so
I
picked
up
on
a
couple
of
themes,
but
I
want
to
get
really
specific
with
them.
So
one
is
the
formatting
and
contents
of
the
leap.
Util
error
message
right,
particularly
with
the
smoke
test
right,
but
maybe
in
general
yeah.
B
B
A
E
Yeah
we
did
make
some
improvements
to
put
that
more,
like
the
esio
version
in
terms
of
recording
there
in
terms
of
hitting
all
the
use
cases,
you
point
out
there
I'm
not
sure
that
that
we
that
we
did,
that
I
would
encourage
you.
You
know
if
you
can
just
throw
all
those
screenshots
into
a
GitHub
issue.
Right,
quick,
you
know
we
could.
E
D
E
D
Circumstantial
though
nobody
has
yeah
like
I
just
yeah,
she
could
be
I'll.
Be
honest.
I
feel
pretty
confident
that
no
you
can't
trim
one
key
trim.
10.
I've
broken
a
lot
of
these
a
lot
of
ways.
You
got
to
go
block
your
mic
and
live
in
and
often
like,
not
exist
anymore,
that
that's
exactly
I,
wonder
if
well,
300
was
the
magic
number
300.
Well,
let's
get
it
can.
E
Be
that
because
we
only
put
irreversible
blocks
in
the
block
log,
that's
the
only
thing
it's
in
the
block
block,
so
they
don't
get
written
now
they
do
get
written
in
a
burst,
because
when
lib
moves,
it
doesn't
just
move
one.
It
moves
whatever
it
moves
like
a
dozen
or
so
so
it
could
be
related
to
to
that.
Maybe
it's
the
maybe
you
have
to
trim
off
at
least
a
dozen
I
I.
Don't
know
that!
D
It's
consistent
enough
that
you
know
I
run
multiple
instances
on
the
same
note,
then,
when
it
happens
to
one
it
has
pretty
much
happened
to
every
single
chain.
On
that
note
now
they
may
all
be
doing
the
same
thing
at
the
tops
of
the
seconds
and
that's
why
they
all
are
at
the
same
state.
But
you
know,
like
I,
mean
I
gotta
believe
like
in
the
process
of
these
half
second
Cycles.
They
would
be
at
different
points.
I
mean
writing.
D
E
I
mean
the
other
thing
we
could
do
like
we
for
State
history,
like
we
think
we
do.
This
thing
called
the
flush
it
to
disc.
We
don't
do
that
for
the
block
log.
You
know
we
can
potentially
do
that
I'm
trying
to
think
I
I.
At
some
point
we
moved
that
to
a
different
thread:
I,
don't
know
if
that's
actually
leak
code
or
only
nsio
code.
I
have
to
go.
E
Take
a
look
at
that
to
to
remember,
but
we
could
we
could
potentially
do
that
which
which
might
help,
but
regardless
you
know
being
no
matter
what
you
do,
there's
the
potential
for
for
corruption.
Unless
we
actually
do
a
complete
file
system-
sync,
but
that's
so
slow,
like
I,
don't
think
we
want
to.
D
Do
that
I've
had
it
eat
the
files
you
know
where
it's
just
like
it
tries
to
validate
it,
and
it
said
nah
man,
this
thing's
bad.
You
know
it.
This
is
and
Brian
to
catch.
You
up.
We
I
guess
kind
of
progressed
from
why
you
need
to.
You
know
why
Roz
is
trying
to
do
something
and
it's
not
working
he's,
trying
to
trim
it
and
fix
it
right
and
what
Kevin
kind
of
picked
up
on
is
is
well.
D
C
D
Maybe
we
could
add
a
like
dash
dash,
rewind
command,
which
then
just
let's
remove
one,
let's
remove
another,
let's
remove
another,
and
then
it
keeps
removing
it
until
it
finds.
Oh
now
we're
good
that's
what
I
was
like
I
mean
I
would
think
that
if
it
could
do
so,
it
was
like
a
lot
of
handling.
Well
I
mean.
Ultimately
it
would
tell
you
where
exactly
it's
the
problem.
So
that
way
we
can
diagnose
this.
You
know:
where
did
it
get
corrupt
problem
right?
D
Because
right
now,
Michael,
you
just
say:
oh
just
trim
a
thousand
because
I
don't
wanna
I,
don't
care,
don't
look
at
it
right!
I
know
it's
got
to
be
more
than
one
right
right.
So
if
we
have
a
tool
that
could
like
dissect
where
the
problem
happened,
then
every
time
you
go
to
repair,
you
could
run
this
and
then
we
could
get
some
data.
That
tells
us
actually
how
many
blocks
it's
corrupt.
D
Let's
see
I
guess
in
my
mind,
I
look
at
it
and
say
the
reason
I
run
into
this,
because
the
node
crashed
I'm,
firing
it
up
I'm,
using
a
snapshot
I'm
trying
to
repair
it
right
and
yeah.
It
hangs
because
it's
saying
I
don't
like
the
data.
If
it's
going
to
start
stepping
its
way
back,
okay
go
to
the
block
before
the
block
before
it
maybe
step
in
12.
D
If
we
think
it's
in
batches
whatever
it
is
it
if
it
would
just
be
like
cool
there's
the
block
that
I
need
to
start
from
and
take
it
and
go
from
there.
Ross
and
I
wouldn't
have
to
be
using
the
damn
utility
to
begin
even
better.
That
all
I
say
is
that
it's
a
handling
of
it
and
the
tool
to
even
figure
out
where
is
it
not
broken
at
cool?
Now
that
you
figure
that
out
there
yeah.
C
D
Yeah,
but
this
has
to
be
an
Arsenal
parameter
right,
because,
if
you're
on
a
network
where
you
are
the
only
block
producer,
the
last
thing
you
want
to
do
is
auto.
Remove
blocks
right.
But
if
you're
on
a
public
network
totally
fine
remove
blocks
whatever,
because
we
can
only
get
what
you're
saying.
But
in
the
context
of
that
note,
you're
screwed,
because
you
can't
use
that
block
log
anymore
until
yeah,
but
maybe
possible
to
extract
some
data
out
of
that
block.
Log
I,
don't
know
I'm
just
being.
C
That's
what
the
tool
will
do
anyway,
right,
like
the
tool,
will
find.
Where
is
the
last
block
that
it
can
read
correctly
and
continue
from
there?
So
I
guess,
even
if
you
are
your
own
producer,
loan
loan
producer
will
still
work,
although
I
do
like
it
at
the
option,
because
it
does
change
functionality
from
what
people
are
using
so
kind
of
like
a
node.js
auction
like
auto
repair
or
something,
and
that
would
allow
you
to
try
those
things
automatically.
D
Yeah
yeah,
so
I
I.
Definitely
like
the
option
of
do
all
the
right
things
and
I.
Don't
care
just
start.
My
node,
you
know,
which
is
great
for
public
networks
and
for
the
private
Network,
where
you're
the
only
node
on
the
whole
network.
Well,
don't
run
that
out.
I
just
I
mean
I
get
what
you're
saying
but
I
mean
in
my
mind
this
is
only
related
to
a
snapshot
or
store
right,
because
this
is
what
it's
trying
to
do
launch
from
a
snapshot,
and
it's
really.
D
It's
gonna
try
to
replay
the
block
log,
but
when
it
gets
this
unpack
a
doesn't
equal
b
error,
you're,
screwed,
you're
I
mean
I,
actually
think,
but
you
should
have
to
text
that
before
I.
Think
if
you
do
a
replay,
if
you
had
to
do
a
whole
replay
and
it
got
to
the
end
of
the
block,
it
blows,
yeah
I
do
still
go
up.
D
So
it's
not
just
that
it
is
well
it's
the
snapshot,
but
then-
and
it
goes
to
replay
after
that,
when
it
hits
that
last
Block
they'll
say
that
let's
say
that
you
were,
you
know
insane
to
replay
an
entire
block.
Blog
on
one
of
the
pub
actually
okay,
you
know
what
Matthew,
if
we're
running
it
on
your
private
Network
and
you
know,
you've
only
got
a
million
bucks
or
something
inside
of
them
when
you
replay
it.
If
it's
damaged,
it's
also
going
to
damage
so
ultimately
yeah
for
sure
made
regardless
yeah
correct.
D
That's
what
I
say
is
if
you're
restoring
a
snapshot,
and
it
knows
that
log
I
mean
there's
not
much
unless
maybe
it
you're
running
these
two
I
gotta
try
to
date
an
artist
out
of
the
corrupted
block
log.
That
should
be
the
switch
because
from
a
user
experience
there
ain't
nothing
that
makes
sense
about
beta
unpack,
Ada
3.,
so
at
least
they're
handling
it.
But
really
that's
what
I
say
if
you
just
go
back
a
little
bit,
the
whole
snapshot
recovery
process
can
get
that
node
fixed
because
your
blocks
are
gone.
There's
no
deal.
C
So
like
like
one
idea
is
no
dios
itself
could
check
the
state
of
the
block
log
before
attempting
to
apply
a
snapshot
before
attempting
any
of
this
thing
and
then,
when
it
tries
to
apply
snapshot,
it
checks.
Okay,
there's
already
a
block
slot
great,
let's
check
if
the
snapshot
takes
place
before
or
after
the
last
corrupted
and
potentially
decide
that
way.
D
Yeah
I
mean
it
pretty
quickly,
figures
out
that
it
doesn't
like
the
block
logs
I
mean
it's
not
like
you
waste
a
lot
of
effort.
You
can
fire
it
up
and
immediately
you
get
an
unpack
error
and
then
no,
no
so
but
I
mean
you
could
do
it
on
Startup.
But
in
my
opinion,
it's
kind
of
error,
handling
of
this
snapshot
or
even
the
replay
that
says.
B
A
B
You
know,
then,
the
more
fundamental
issue
here
is
that
block
logs
get
corrupted,
and
ideally
we
would
minimize
the
causes
of
block
logs
getting
corrupted
failing
that,
we
want
an
easy
way
to
diagnose
the
cause
of
corrupted
block
logs
and
a
way
to
more
easily
recover
from
corrupted
block
logs
at
at
a
10
000
foot
view
is:
is
my
understanding
right
or
am
I
missing?
The
Mark
here.
D
D
B
If
that's
all
right,
a
topic
occurred
to
me
that
actually
I
would
like
to
get
feedback
on,
but
also
I
want
to
kind
of
keep
the
open
floor
first.
So
are
there
any
other
topics
that
folks
want
to
cover?
Michael,
had
sort
of
release,
Cadence
feedback
and
and
stuff
that
we
could
go
into
any
other
topics.
B
Okay,
I'll
throw
my
topic
out
there,
which
is
one
one
area
that
we're
exploring
as
part
of
a
larger
initiative
is
attempting
to
you
know
which
I
mean
this
is
one
of
those
obvious
and
very
large
subjects,
but
attempting
to
reduce
the
the
expenses
involved
in
running
a
node
and
there's
kind
of
two
ways
of
looking
at
that,
which
is
one
just
in
general.
What
what
it
takes
to
be
a
node
operator
for
an
antelope,
Network
and
then
another
way
of
looking
at
it
is
incrementally.
B
C
B
A
B
Said
was,
you
know,
hey
we're
talking
about
5.0,
but
many
of
the
node
operators
and
even
block
producers
have
not
necessarily
upgraded
to
a
4.0
version
and
there
We've
recently
released
patch
releases
fixing
some.
You
know
potential
stability
issues
with
4.0
prior
versions,
and
there
are
some
new
outstanding
bug.
Reports
too,
that
need
to
be
sort
of
triaged
and
determined
if
they're,
critical,
the
first
thing
as
so
I'll
speak
on
this
a
little
and
then
also
just
kind
of
get
open
feedback
and
just
sort
of
listen.
B
B
Obviously,
the
US
Network
Foundation
doesn't
have
any
direct
controller
influence
over
like
when
these
things
are
actually
ruled
out,
and
so
that's
something
that
requires
Community
coordination
and
can
take
some
indeterminate
amount
of
time
to
get
done
right,
and
so
you
know
the
longer.
We
delay
getting
a
release
candidate
and
going
through
sort
of
the
process
of
of
building
confidence
that
those
are
rock,
solid
and
stable.
B
You
know
which
in
and
of
itself,
is
going
to
be
a
period
of
time
that
this
takes
right
and
then
and
then
finally,
the
sort
of
coordination
process
of
getting
people.
You
know
upgraded
and
ready
to
go
and
then
finally
getting
people
to
actually
activate
you
know.
Protocol
features
right,
it's
a
it's
a
long
process
and
at
we're
we're
basically
from
a
Cadence
perspective.
B
So,
given
that
big
sort
of
lead
time
that
I
just
described
right,
if
we
have,
if
we
don't
what
am
I
trying
to
say,
if
we
have
delays
on
that
right,
it
has
the
risk
of
pushing
the
next
one,
because
it
could
take
a
lot
of
that
window
time
right
just
just
to
get
to
that
point.
So
it
has
the
risk
of
potentially
pushing
the
next
one.
And
you
know
at
some
point
it's
you
know
less
than
two.
C
Ahead,
I
think
just
elaborate
on
my
remark.
It
was
more
about
Trying
to
minimize
cost,
because
at
the
end
of
the
day,
your
server,
no
matter
what
you
do,
you
know
EOS,
you
still
need
the
RAM
and
you
still
need
like
Fast,
potentially
CPU
and
a
lot
of
disk
space.
So
the
optimization
that
I
see
happening
are
more
like
about
how
many
like
the
steering
up.
C
B
Yeah
and
and
I
understand
what
you're
saying
the
the
context
of
your
comment
was
around
cost.
The
reason
I
went
into
this
was
because
the
reason
that
folks
haven't
necessarily
yet
reaped
the
benefits
of
4.0
is
because
many
haven't
actually
upgraded
to
4.0
yet
and
which,
which
was
very
relevant
to
Michael's
comment,
so
that
yeah
that
all
makes
sense
anyway.
A
A
B
Everything
I
just
said,
but
one
more
bit
of
context
is:
there
are
really
two
primary
features
targeted
for
5.0
that
are
like
we.
We
really
want
to
make
sure
they're
in
there
right.
The
first
is
the
is
the
protocol
upgrade
feature
that
we're
targeting
which
is
instant
finality,
so
we
really
hope
to
have
that
in
there
and
we
think
that
that
one's
important
enough
that,
like
potentially
this
is
this-
is
Brian
talking,
not
a
official
es.
Network
Foundation
statement
still
need
to
like
get.
B
You
know,
people
aligned,
which
might
mean
me
moving
on
this
right,
but
potentially
delaying
5.0.
If
that
isn't
ready
right
most
other
things
would
not
like.
If
that's
ready
and
other
things
are
not,
we
would
ship
it
without
the
other
things
you
get.
What
I'm
saying
so,
that's
sort
of
the
the
Cornerstone
feature
that
we
hope
to
include
in
5.0
and
then
the
next
one
is
the
we
talked
about
the
vmoc
features
which
PRI
the
primary
purpose
of
that
is
to
offer
performance
benefits
for
the.
D
B
B
Right
so
basically
it
applies
the
for
producers
as
well
in
certain
scenarios,
but
not
in
all
scenarios.
There's
a
there's,
an
issue:
Kevin
I,
wonder
if
you
could
paste
that
link
in
into
the
chat,
so
people
could
take
a
look
at
it.
It
has
a
table
which,
which
goes
through
sort
of
the
conditions
where
OC
would
be
applied
now
with
producers
as
well
anyway.
So
those
the
those
are
the
two
like
primary
features
that
we
hope
will
will
definitely
be
in
5.0.
C
Ahead,
I
was
just
going
to
say:
that's
definitely
more
reason
to
do
it
as
soon
as
possible,
because
with
faster
penalty,
there's
gonna
be
a
lot
of
synchronization
between
you
know,
exchanges
and
making
sure
everybody
is
expecting
it.
It's
like
a
lot
of
you
know.
User
interfaces
are
counting
the
blocks
and
versus
you
know
chatting
what's
the
lid
you
know
so,
like
I
love,
this
like
like.
Do
we
need
people
enough
room
to
to
adjust
to
basically
make
benefit
of
this?
C
B
Right
now,
the
headline
here
that
I
mentioned
at
the
very
beginning
of
this
call
is
that
there
are
other
items
that
are.
The
work
is
continuing
on
them,
they're
they're
being
done
in
in
in
parallel,
but
they're
candidates
for
potentially
moving
into
a
future
release
so
as
not
to
delay
the
5.0
release
right
and
those
those
Cornerstone
features
anyway.
I'm
going
to
stop
talking
about
this
now
and
let
other
people
give
any
additional
context
or
feedback
on
release.
Cadence
stuff.
A
Okay,
I'll
go
so
just
just
a
little
bit
of
yeah
on
the
Cadence
side
of
things
when,
when
it
comes
to
the
consensus
upgrades,
what
we
found
with
the
previous
ones
is
that
generally
rule
of
thumb
giving
two
months
from
the
time
we
have
the
final
release
and
all
the
documentation
nicely
ready
and
an
article.
Basically
one.
A
That's
already
we
get
the
EO
support,
guys
to
go
start
sending
out
emails
and
knocking
on
doors
and
usually
about
two
months
is,
is
an
appropriate
amount
of
time
to
get
everybody
prepared
for
the
consensus
upgrade
and
I
can
also
say:
I
added
chat
with
Eve
just
to
pick
his
brain.
Is
there
any?
You
know
strategic
reasons
to
Target
any
particular
date
for
the
activation
and
from
from
Eve's
perspective?
Really
it's
just.
A
We
want
to
avoid
getting
into
the
holiday
season
so
December
and
the
western
side
of
things,
and
then
we
got
Chinese
New
Year
lunar
year
kind
of
I
think
in
January
February.
So,
ideally,
the
goal
would
be
to
activate,
but
before
the
end
of
November,
which
gives
us
until
September
to
get
final
release
out
and
and
all
the
documentation
prepared
and
and
the
comms
going
out.
B
B
So
the
biggest
question
mark
that
I'm
that
I'm
digging
into
because
I'm
not
directly
involved
in
it
is
the
most
important
feature
which
is
instant
finalities,
though
I've
got
some
more
digging
to
do
to
understand
where
that,
where
that
lies
and
whatnot,
but
but
yeah.
So
that's
the
reasoning
for
the
release.
Cadence.
It
sounded
like
I.
Think
Shaq.
If
you
had
a
question.
C
Yeah
I
just
wanted
to
ask
if
something
has
changed
regarding
the
OC
and
when
it
was
first
into
introduced,
but
I
do
remember,
there
was
conversation
about
not
to
enable
it
for
a
few
reasons.
One
of
those
reasons
was
that
I
think
history
Solutions
won't
be
able
to
keep
up
or
or
nodes
to
sync
from
Star.
What's
going
to
be
an
issue
to
actually
catch
up
like
I,
don't
recall
exactly
but
I
just
wanted
to
know.
If
these
issues
are
no
longer
an
issue
because
they're
addressed
in
a
different
way
or.
B
Well,
this
is
this
is
one
of
the
reasons
that
we
want
to
bundle
it
with
a
protocol.
Upgrade
release
is
because
so,
for
example,
maybe
Kevin
probably
could
speak
more
instantly
on
this,
but
like,
for
example,
the
the
concern
over
history.
Solutions
is
valid,
but
is
only
a
problem
if
those
history
Solutions
are
not
running
an
updated
version
that
that
takes
advantage
of
of
OC
in
this
for
the
same
set
of
transactions
that
a
that
the
network
in
general
is
is
doing
right,
yeah
the
concern
at
a
high
empty.
They.
C
You
know
an
issue,
but
in
theory
like
because
you
know
in
diffuse,
you
could
run
like
different
nodes
and
have
them
say
different
parts
and
then
just
combine
all
the
merge
blocks,
for
example.
So
you
can
scale
it
that
way
to
capture
if
we
have
the
same
way
for
State
history,
where
you
might
have
I,
don't
know
multiple
nodes
and
then
kind
of
join
the
state
history.
That
activities
will
resolve
it
for
catching
up.
C
B
And
the
the
biggest
reason
why
that's
potentially,
a
risk
is
like
what
we
call
a
10
000,
X
sort
of
computational
difference.
Right
like
it's.
You
know,
orders
of
magnitude,
potential
difference
between
the
efficiency
of
OC
versus
Baseline,
and
that's
also.
One
of
the
reasons
for
the
selective
usage
of
OC
is
that
by
only
rolling
it
out
for
system
contracts
and
other
very
specific
scenarios
like
like,
for
example,
read-only
transactions
right
those
sorts
of
things.
B
C
B
Yeah
Custom
Contract
intentionally
creating
a
10,
000
X
scenario
right
where
it's
something
runs
way
faster
on
OC
by
several
orders
of
magnitude
than
on
Baseline
and
therefore
creating
these
issues
right.
So
instead
we
we're
limiting
to
more
in
the
you
know,
like
5x
type
of
category
right,
where
it's
it's
significantly
more
performant,
but
not
so
much
so
that
it
creates
an
untenable
situation.
All.
C
Right,
that's
I'm,
not
kind
of
a
situation
will
be
only
if
new
period
like
ship
is
not
using
OC,
for
example,
and
you're,
trying
to
sync
with
a
node
or
a
producer
that
is
doing
hosting
because,
like
some
things,
like
you
said,
like
read,
only
transactions
return
values,
maybe
they're
in
Recon
transaction.
All
those
things
like
will
definitely
benefit
from
obviously,
and
potentially
system
contracts
as
well,
although,
like
I,
don't
see
why
you
can't
even
enable
it
for
the
rest,
it's
good
thing
now
as
long
as
you're
using
an
updated.
C
E
E
Definitely,
if
you've
got
a
a
node,
that's
dedicated
to
ship,
then
yeah,
absolutely
you
should
enable
OC,
because
there's
no
reason,
there's
no
reason
not
to
the
the
same
could
potentially
be
said
for
a
PDP
note
like
if
you
had
a
node
whose
only
job
was
to
provide
P2P
a
relays
and
connections,
then
there's
really
no
reason
not
to
enable
OC.
On
that
note,
unless
that
node
is
directly
connected
to
your
BP
and
then
you
potentially
don't
want
to
run
it
on
that
node.
So
what
this
does
change
subjective
billing.
C
E
E
And
you
know,
if
that
that's
the
case,
then
you
don't
need
the
protection
necessarily
on
the
relay
all
depends.
You
know,
of
course,
on
your
setup,
the
one
of
the
real
benefits
here
with
this
Auto
ooc,
you
wouldn't
talk.
We
can
talk
some
more
about
the
producer
in
issues
that
that
might
cause
in
terms
of
like
security,
and
we
can
talk
some
more
about
that
if
you
like
but
like.
Let
me
just
talk
about
one
of
the
big
benefits
of
this
change.
Is
that
is
like
running
it.
E
This
auto
mode,
which
will
be
the
default,
will
be
in
place
on
your
API
note,
which
means
on
an
API
node
when
you're
running
your
transactions,
specularly
executing
transactions
that
come
through
the
API,
the
RPC
endpoint,
then
those
will
run
and
we'll-
and
you
know
the
default
without
OC,
and
so
that
gives
you
like
the
equivalent
sort
of
of
like
billing
capability
so
that
you
can
report
back
to
the
user.
You
know
presuming
same
Hardware
et
cetera,
et
cetera.
C
Want
OC
to
be
like
like
say
this,
auto
mode
that
is
set
automatically.
It
should
be
the
same
in
my
opinion
as
the
BP,
so
meaning
that
it's
enabled
for
system
contact.
It's
enabled
for
you
know
whatever
else
like
that
that
will
be
enabled
for
in
the
BP.
Otherwise
the
API
will,
you
know,
might
report
like
a
higher
cost,
because
it's
not
doing
OC
and
not
let
the
transaction
pass.
E
Yeah
yeah
and
then
actually
that
is
exactly
the
way
it
works
so
for
esio.star
contract.
So
anything
that's
on
an
esio
system,
account
contract.
So
that's
you
know
the
system
contract,
that's
the
token
contract.
It's
the
EOS
evm
contract,
which
is
kind
of
key
here.
Eos
IO
wrap
multi-fig
all
those
the
contracts
that
are
on
an
efio
account,
then
no
matter
where
you're
at
on
all
nodes.
E
They
will
use
OC
and
the
rationale
there
being
that
those
are
all
controlled,
accounts,
well
tested
and
understood,
and
so
they're,
not
just
a
user
controlled
accounts.
They
are
system,
controlled
accounts
and
so
we're
deeming
it
safe
to
run
OC
on
all
those
accounts,
because
the
the
contracts
are
controlled.
E
It's
going
to
be
hard-coded
to
the
config
and
the
source
code
of
system
account
which
is
esio.
So
if
someone
has
modified
their
code
base
to
change
the
esio
system,
account
name,
then
that-
and
they
merge
this
in
assuming
they
do
the
merge
correctly
then
yeah
yeah,
then
it
will
use
that
it
will
use
that
config
variable.
So
it's
not
hard-coded
exactly
the
esio,
although
it's
it's
system
account
which
is
hard-coded
gsio,
at
least
in
in
our
code
base,
so
yeah.
E
Certainly
someone
can
easily
change
that
on
a
on
a
on
a
sister
chain,
if
they've,
if
they've
already
done
that-
and
they
want
to
continue
to
do
that-
otherwise,
yeah
it's
associated
with
that.
We
did
discuss
the
possibility
and
we
could
still
discuss
this
as
potential
changes
in
the
future
of
adding
a
white
list
capability.
So,
instead
of
just
saying,
efio,
instead
potentially
have
a
ability
for
say,
block
producers
to
multifig
configure
a
set
of
contracts
that
that
that
are
whitelisted
for
for
OC,
but
for
now,
at
least
in.
E
If
initial
release
that
we're
talking
about
it'll
be
strictly
for
esio.accounts,
of
course,
when
the
big
ones
there.
Of
course,
our
token,
which
token
transfers,
which
are
a
large
portion
of
what
the
chain
does
right
and
then,
of
course,
the
other
big
one
there
is
for
Eos
evl
right.
So
you
get
the
speed
up,
Freeview
and
so
that'll
be
across
the
board,
so
whether
the
account
is
and
whether
it's
yes,
the
default
on
block
okay,
unblock's
interesting
I,
have
to
go.
E
Look
at
unblock
yeah,
that's
okay,
I,
don't
know
off
top
my
head
I'll
go
check
that
out:
I
I'm
guessing
yes,
but
I
wouldn't
swear
to
it
at
the
moment,
but
yeah.
Let's
make
sure
on
Block
it's
it's
that
as
well.
If
not
I'll
make
sure
that
happens.
Yeah,
that's
a
good
point.
I'll
make
sure
that
so
I
think
so
because
it
should
be
es
effectively
esio
system
contract
in
play
there.
E
So
yeah
pretty
certain,
that's
true,
but
I'll
verify
but
yeah,
so
esio,
and
so
that's
cross-board
where's
the
producer,
whether
it's
the
API
node,
but
no
matter
where
an
esio.star
contract
action
executes
it
should
be
in
OC.
After
this
change,
assuming
you
haven't
explicitly
disabled
OC,
which
you
can
you
can
still
say,
tear
up
none,
but
the
default
will
be
Auto.
You
can
still
use
all
like
if
you're
on
the
ship
node,
you
still
want
to
enable
it
for
all
contracts.
E
You'd
still
be
running
it
for
all
cases
for
ship,
it's
just
for
like
API
nodes,
you
get
the
benefit
of
the
of
executing
it
for
the
sio
account,
but
the
other
huge
benefit,
and
this
is
across
the
board
on
every
node
that
that
that
would
be
running
this
auto
mode.
It
enables
OC
for
applying
the
block.
So
when
you
receive
a
block,
it
would
apply
the
block
using
those
fee,
even
though
speculative
execution
is
done
on
non-oc,
so
before
nodes
had
like
just
basically
on
or
off
right,
either
all
or
none.
E
E
That's
enabled
got
enabled
OC,
but
the
BP's
also
got
enable
OC.
Well,
let's
say
it's
the
the
worst
case.
Well,
I,
don't
know
it.
Let's
have
don't
call
the
worst
case.
Let's
just
say,
we
have
a
scenario
that
every
transaction
for
a
month
is
on
an
efao
account.
It's
either
a
token
transfers
or
an
evm
right.
Bbm
became
so
popular
that
no
one's
doing
anything
else,
and
and
that's
all
that's
happening
so
yes.
E
Now
in
general,
it
should
be
able
to,
because
you
know,
you've
got
change,
parameter
set
where
we're
only
using
200
milliseconds
out
of
the
500
milliseconds
of
time
of
a
block
time.
So
that
gives
you
know
300
milliseconds
more
time
to
a
ship
node
in
general.
Right
and
those
can
be
scaled
right.
I
mean
you
can
change
the
CPU
effort
percent
to
even
scale
that
back
more.
If
you
find
out,
you
know,
the
your
BPS
are
too
powerful,
like
they're
just
overwhelming
the
network
I
mean.
Certainly
it's
BPS.