►
From YouTube: Node Operator Roundtable - February 22nd, 2023
Description
This week the EOS Node Operator Roundtable updates the community on software development and has a detailed discussion on DeepMind logger node, State History node, Event Capture service, and History Provider service as they move into Layer 2 solutions.
00:00:00 Start
00:00:02 Welcome to the Node Operators Roundtable
00:00:26 Software development update
00:02:39 Special Node Type technical discussion
00:03:11 DeepMind Logger node
00:09:36 State History node
00:37:33 Event Capture service
00:43:40 History Provider service
00:46:11 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
B
C
B
So
first,
you
know
we
need
to
sort
of
capture
a
description
of
what
these
things
are
and
agree.
Us
agree
if
they
are
indeed
a
thing
so
for
the
deepmind,
logger
node
I
think
I'll
go
to
Matthew,
because
I
know
he's
a
consumer
of
this,
so
it
first
Matthew
would.
Would
you
propose
that
this
is
indeed
a
sort
of
a
special
purpose
that
a
node
plays
or
or
not.
D
B
D
I'd
also
say
it's
probably
fair
to
say
that
if
you
do
this
site,
it
can't
do
much
else
because
of
the
way
it's
spewing.
The
data
out
I
mean
it's
like.
If
I
just
launched
it
as
a
regular
node
and
didn't
consume,
it
then
trim
it.
It
was
just
blow
it
out
logs
because
it
was
just
like
streaming
out
massive
amounts
of
baby.
D
Not
necessarily
is
this
dial,
maybe
on
a
different
machine
yeah,
it's
basically
White.
It's
almost
like
running
State
history,
but
always
can
having
to
consume
it.
You
know
what
I
mean
it's,
it's
not
even
really
just
kind
of
writing
it
to
be
called
at
a
time.
It's
an
actively
spewing
data
out
anyway,
point
is
is
that
it
definitely
tends
to
be
a
dedicated.
No
all.
D
But
is
it
fair
to
say
that
deep
mind
portion
of
it
really
is
just
spitting
out
I?
Think
it's!
The
one
block
follows
right:
it's
spinning
out
a
lot
longer,
treats
the
well
whatever's
happening
on
the
blockchain
to
standard
out
what
happens
after
that
is
up
to
you,
but
the
purpose
is
to
read
the
standard
out
and
then
do
something
with
it,
which
is
relay
those
blocks
to
other
components
that
are
listening
and
then
write
the
one
block
files
to
this
you're,
not
just
running
the
node
just
to
spit
out
logs
right.
D
You
need
to
actually
do
something
right
and
I
guess
that
was
the
point.
I
was
kind
of
making
that
I
mean
something
needs
to
be
consuming
that
stand
that
out,
whereas
the
other
ones
are
really
kind
of
a
little
more
active,
just
kind
of
collecting
data.
When
you
ask
for
it,
you
get
it,
but
anyway
it's
it's
a
unique
beast,
but
it's
basically
just
spewing
out
Raw
block
data.
F
D
A
Yeah,
and
so
the
purpose
was
originally
to
feed
diffuse,
but
now
it's
also
the
it's
the
same
thing.
That's
stating
now
the
new
version
of
fire
hose
and
which
feeds
substrings,
which
is
what
is,
is
kind
of
the
new
stack.
That's
powering
the
graph
protocol
and
all
these
other
blockchains
are
running
the
stack
and,
and
one
of
the
things
we
know.
This
is
something
we've
been
running.
A
Very
things
of
a
lot
of
things
we
really
appreciate
about
antelope
is
how
this
is
baked
right
into
the
core
and
tulip
software
if
you
want
to
run
fire
hose
on
ethereum
or
any
other
chain.
As
far
as
I
know,
I
don't
know
if
there
are
any
other
chains
that
haven't
baked
in
you
have
to
run
a
fork
of
that
of
their
node
software
to
be
able
to
run
fire
hose
so
for
folks,
operators
and
Antelope.
D
D
C
D
Okay,
good
days,
right
and
I
said
the
the
the
thing
that
we're
in
the
middle
of
discussing
and
we're
going
to
send
out
a
survey
on
it.
Is
that
a
console
logging
or
in
printf
statements
from
your
contract,
so
you
know
diffuse,
or
these
can
get
emitted
in
the
event
blog
to
do
something
with
and
one
of
the
things
we're
wondering
about
is:
should
we
have
a
standard
way
that
this
is
configured
I
was
going
to
mention
that
under
State
history,
because
that's
where
we
run
into
it,
the
Anna
would
need
it
yeah.
D
It's
the
same.
It's
the
same
question
because,
like
somebody
could
output
a
printf,
that's
like
a
gigabyte,
maybe
not
a
gigabyte,
but
you
know
it
could
be
huge
right.
It
could
be
a
Ghostbusters
logo
yeah
exactly
so.
The
question
is,
you
know.
Maybe
we
should
put
a
limit
on
this
thing
and
not
allow
that
I
I'm
I'm,
not
sure
what
people?
What
because
I
don't
know
what
are
all
the
uses
for?
Why
do
people
want
to
capture?
That's
what
I
was
gonna
say
that
seemed
to
always
kind
of
be.
D
The
original
question
was
well.
Why
are
you
using
console
logging,
that's
kind
of
statio
per
node
type
of
thing,
and
it's
because
that's
how
some
of
the
mechanisms
I
think
like?
If
you
know
it's
going
to
a
surge
and
want
to
be
able
to
respond
to
it?
I
think
is
one
of
the
ways
some
of
our
layer
Tunes,
you
know
I
mean
or
it's
not
actually
on
chain,
but
because
the
service
is
using
it,
and
and
that's
also
why
our
ship
nodes
are
relaying
API
requests.
D
That
then
makes
my
State
history
different
than
everybody
else's.
It's
not
like
my
block
log
is
identical
to
everybody
pick
it
up.
I
can
move
it
around,
there's
no
difference
between
what
I
have
and
what
Matthew
asked.
In
dear
my
State,
history
follows
that
that's
not
true
anything
that
it
might
know
console
logging
because
they
were
using
them.
It
made
its
way
into
State
and
it
tripped
up
Atomic
indexer
one
a
couple
times
actually
and
I'll
be
not
happy
about
that.
But
Point
wise
is
that
we
found
out
the
hard
way.
D
B
C
And
hugees
up
poor
man's
events,
unfortunately,
and
we
we
talked
about
adding
true
events
to
the
absolute
protocol,
but
that
hasn't
happened.
So,
unfortunately,
people
use
logging
as
a
poor
man's
okay,
a
mechanism
for
the
history
plug-in.
You
know
there
is
a
way
of
running
it,
that
you
get
deterministic
output,
but
that
does
not
I
believe
the
the
console
which
it
might
make
sense
to.
C
C
Yeah,
so
currently
what
happens
is
you
can
run
the
history
plugin
in
one
or
two
modes?
One
badge
deterministic
of
one:
that's
not
currently
the
non-deterministic
way
of
running.
That
is
the
way
that
includes
the
console
logging,
which
is
why
people
choose
to
run
it
that
way,
but,
along
with
that,
you
get
as
Michael
was
talking
about
non-deterministic
information.
So
it's
typically
like
ctus
right,
which
is
not
not
deterministic.
C
Now
you
know
you
put
the
bills,
which
is
is
deterministic
and
I'm,
not
sure.
If
the,
if
the
running
State
history
in
the
in
the
deterministic
mode
includes
that
or
not
Iraq
and
cattle,
but
I
mean
that's
the
distinction,
so
I
mean
you
know.
Potentially
we
could
do
something
like
on.
One
thing
you
could
do
is
just
say:
well,
if
you're
running
ship,
you
have
to
enable
Contour
log
and
then
everyone
would
get
caught
to
logging
and
all
their
now
I,
don't
know
what
that's
anybody.
D
C
D
C
It
hit
volume
is
slow,
I
mean
you
can
mitigate
that
a
little
bit
because
you,
you
can
actually
turn
on
contract
console
output,
but
not
actually
log
it.
Those
are
two
distinct
settings
which
so
it's
a
lot
more
like
it'll
wind
up
in
your
ship
and
it
won't
actually
be
logged
to
cocktail,
which
is
you
know,
that's
the
full
part.
The
Footwear
is
actually
log
into
the
console.
Oh
sorry,
Kevin
yeah,
so
I
mean
I,
mean
there's
some
things
that
could
potentially
be
done
there.
D
B
D
So
so
yeah
I
think
it's
worthy
of
a
discussion
about
you
know
where.
Where
can
we
just
chop
this
on
all
agree
that
where
we
should
chop
it
and
then,
even
though
it's
not
yeah,
we
we
really
need
to
fix
the
the
root
problem,
which
is
have
a
proper
event
system
whatever.
But
until
then
we
all
agree
we're
going
to
chop
it
at
X
and
amount
of
characters,
and
then
you
know
that's
it
and
that
prevents
I.
F
Mean,
unlike
the
odd
you're
right,
limiting
and
also
potentially
putting
like
a
contract,
white
and
Blacklist
on
it
as
well.
So
then
you,
you
only
get
logging
output
from
specific
contracts,
so
you
might
want
to
specify
that
doesn't
make
the
the
output
deterministic
but
I'm
wondering
what
the
requirements
are
like
a
deterministic.
His
like
history
at
that
point
is
anyway,
I
mean
you've
already
got
the
block
sold.
You've
already
got
the
state
that
can
be
recreated
if
necessary.
D
So
when
we're
talking
about
enjoyment,
no
so
for
State
history,
maybe
not
for
father
of
those
blocks
in
the
graph
ecosystem,
we
want
to
enable
things
like
multiple
providers
providing
blocks
and
and
then
you
want
to
give
the
crew
that
their
all
providers
have
the
same
thing
so
either
you
could
just
check
some
little.
You
know
storage
thing
or
you
would
have
to
come
up
with
an
algorithm
that
says
well
yeah,
but
this
guy
has
console
logging
in
this.
D
F
Up
really,
the
only
thing
I'm
thinking
of
is
to
use
in
terms
of
like
the
AVM,
and
this
could
potentially
be
a
deprecated
feature
as
well,
but
like
if
there's
like
a
hard
limit
put
on
the
output
to
the
console
logging,
then
that
could
potentially
affect
like
Downstream
functions
that
rely
on
the
the
log
output
yeah
like.
If
you
can
only
get
sort
of
like
X
number
of
characters,
then
it
might
actually
need
more
characters
than
that.
Well,
that's
why.
D
We
need
to
figure
out
what
things
people
are
using
for
and
how
many
characters
they
need
like,
but
80,
000,
characters
and
console
log
is
not
reasonable.
Right.
I
think
you
ultimately
kill
the
Global
acceptance
of
everybody.
Turning
on
Console
logging,
if
it
has
that
open-ended
exploitability,
but
can
we
find
a
happy
medium
to
where
okay
is
80,
80
92
a
better?
You
know
sorry.
C
I
mean
the
position
in
the
past
has
been.
You
know
what
from
the
core
team
or
whoever
that
you
know
you
shouldn't
be
doing
this
right.
I
mean
come
up,
but
yeah
people
still
do
so
because
they
have
no
answer
was
don't
do
that
as
opposed
to.
Let's
try
to
come
up
with
a
limit,
or
you
know,
do
this.
It's
the
answer
was
no
stop.
That's
not
what
that's,
for
you
know,
use
inline
action.
Instead,
you
know
that
that's
what
it.
B
Means
publishable,
with
this
rally
like
a
w3c
like
one
of
the
ways
that
they
approach
things
is
they
they
will
not
consider
a
feature
until
they
see
hacks
being
built
in
the
wild
right
like
so
they
want
to
see
the
the
wrong
way
that
people
are
doing
it
and
then
they'll
build
the
quote-unquote
right
way
for
people
to
do
it.
You
know
so
I
think
I
think
the
fact
that
people
are
doing
it
is
an
indicator
that
there
is.
There
is
something
of
value
here
for
us
to
consider
for
sure,
but.
C
Honey
you
can,
you
can
do
the
right
thing
today
right.
The
right
thing
would
be
to
do
an
inline
action
and
right
and
Max
in
your
trades.
That's
deterministic,
it's
it's
there.
It
it
it's
built
for
it's
all
proper,
like
that's
the
way
it
should
be
done
now.
Yeah.
We
could
wrap
that
up
into
a
knife
a
bit
a
mechanism.
No
we'll
talk
about
doing
that,
but
I
mean
the
right
way
today.
Do
you
think,
like.
C
D
I'll
say
that
the
people
that
have
tended
to
do
this
I
mean
there's.
Obviously
a
lot
of
people-
I
don't
know,
but
they
are
pretty
smart
individuals
in
a
very
in
tune
with
what
the
software
can
do
matter
of
fact,
many
of
them
were
opinion.
You
probably
Kevin
and
the
crew
years
ago,
so
I
mean
it's.
It's
not
like
a
lot
of
people
use
history
because
they
don't
know
how
to
you
know
properly,
look
at
their
information
on
the
Chain,
that's
more
of
a
you're
not
doing
it
right
and
you
should
do
it
better.
D
C
Would
be
interesting
to
get
feedback
from
those
guys?
Why
did
they
choose
Brian?
Do
you
know
our
full
output,
as
opposed
to
an
inline
action?
Was
there
was
the
the
limits
on
the
inline
action
to
to
all
of
us
for
what
they
they
needed
to
achieve?
Or
was
it
simply
it's
cheaper
to
use
the
console
Outlook
in
case
you
don't
have
to
pay
for
it.
You
know,
and
if
that's
the
answer
well
then
no.
B
B
I
think
that
we
have
gone
a
little
long
on
this
I
do
want
to
check
a
theory
here
to
see
if
this
is
true
and
Ryan
asked
the
question
about
like
deterministic
State
and
why
it
matters.
Is
it
true
that
if
we
had
better
sort
of
state
history
determinism,
then
that
could
have
implications
to
sort
of
standardizing
State
history
providers
down
down
the
road?
Does
that
make
sense?
What
I'm
saying
like
because
you'd
have
provable
State
you
would?
You
would
be
able
to
sort
of
trust,
State
history
providers.
D
B
And
then
I
think
you
know,
based
on
what
something
Michael
said
about
like
I,
have
to
have
the
logging
part
of
my
state,
because
otherwise
this
use
case
doesn't
work,
but
then
this
other
contract
does
logging
in
a
way.
That's
not
good
and
I'm
stuck
with
it.
It
seems
to
like
there
might
be
a
case
for
determinism
of
partial
state
right
like
where,
if
you
didn't
capture
everything
you
could
still
have
provable
determinism
for
the
part
of
state
that
you
did
capture
is
that
scene.
D
B
D
Somebody's
building
yeah,
one
of
the
things
I
was
thinking
of,
is
like
maybe
I
could
keep
console
logging
for
you
know
X
number
of
blocks
and
then
throw
it
out.
So
if
I
was
trying
to
build
like
a
block
Explorer,
for
example,
you
know
I'll
keep
the
last,
you
know
10
000
blocks
or
something
because
that's
what
people
it's
supposed
to
be
used
for,
debugging
right
and
then
after
that
right
it
gets
thrown
out
because
well,
it's
one
for
debugging
I
think
that
some
processes
were
written
for
it
to
be.
D
You
know,
I
mean
an
event
that
they
could
still
see,
even
if
going
back
like
liquid,
so
those
processes
should
be
fixed
yeah.
That's
what
I'm,
arguing
yeah
I
mean
figure
out
what
they're
doing
figure
out.
What's
missing
the
software
change
the
software
to
do
it,
get
those
processes
to
change
and
then
change
the
console
logging
output
accordingly,.
C
D
C
Modes
when
this
all
started
and
that
we
ran
it
in
console,
login
would
have
only
been
in
developer
mode
and
it
never
intended
to
be
run
on
on
any
production
system
anywhere.
It
was
only
ever
intended
for
for
a
contract
creators
to
add
debug
logging
to
the
to
their
contract
so
that
they
could
debug
it
while
they're
developing
the
contract
once
it
was
deployed,
it
was
never
intended
to
actually
be
be
live.
Unfortunately,
we
are
we're
far
down
this
road
of
it
being
used
for
other
persons.
B
B
D
D
Profile,
profound
I
believe
it
takes
all
similar
like
the
mind,
all
the
block
traces,
all
of
that
and
stores
it
in
an
additional
log
file.
So
you've
got
your
block
logs
and
you've
got
all
these
massive
State
history,
loans,
terabytes,
there's
four
files,
two
indexes
that
Elite
and
two
files
are
just
destroyed:
terabyte
terabytes
of
contiguous
fragile
data.
C
D
State
is
ODB,
but
yeah
it's
written,
it
normally
can
have
its
own
location,
although
it
can't
really
be
split
up
other
than
oh.
You
got
11
terabytes
of
files
pick
a
path
to
put
it
on.
It
is
not
like
sliceable,
you
know,
I
mean
it
is
trimmable,
but
you
don't
like
a
block
log.
You
don't
have
any
of
that
previous
history.
So
it's
one
of
the
main
mechanisms.
I,
don't
want
to
say
the
only
mechanism,
because
I
know
Aaron
does
magic
with
Trace
API,
but
State.
D
History
is
what,
in
our
opinion,
most
people
use
to
latch
on
to
a
node
with
the
websocket
and
be
notified
of
either
current
events
going
forward
or
batch
going
backwards.
Think
of
me
indexing
the
whole
chain
of
the
history
into
Hyperion.
It
goes
to
the
state
history
and
says:
give
me
one
two
three
well
Watts
one
thousand
two
thousand
whatever
is.
B
D
D
D
B
E
They're
similar,
this
is
why
I
was
talking
about
a
feature
Matrix
in
chat,
because
State
history
is
like
the
monstrosity
that
does
all
of
it,
whereas
trace
the
trace,
API
just
records
traces,
the
deepmind
vlogger
just
streams,
the
information,
but
doesn't
record
it
and
State
history
records
it.
It
streams
it
and
it
also
stores
it
in
a
way
that
it
can
do
diffs
between
certain
points
in
time.
E
D
That
man
a
well
done
State
history
misses
information
because
it
does
it
on
a
per
block
basis,
whereas
the
deepmind
logger
does
it
on
a
transaction
basis.
You
can
get
the
state
between
each
transaction
there
and
that's
not
happened
in
status.
It's
seasoned
down
to
the
Action
level
right,
yeah
parents,
so
the
Deep
wine
logger
is.
If
you
need
the
details,
then
you
need
to
be
my
logger
yeah
granular
efficient.
D
E
I
think
all
three
serve
a
unique
purpose:
it's
just
some
of
them
serve
multiple
purposes
and
if
we
could
trim
them
down
so
that
way
they
are
well
less.
Each
one
of
them
is
less
than
each
one
could
serve
their
specific
purpose.
Better,
like
ship
could
be
more
lightweight
if
it
didn't
handle
the
same
things
that
trace
and
deepmind
did
and
like
that's
the
other
two
kind
of
do
the
one
thing
already.
D
B
E
This
is
why
everybody
uses
State.
History
is
because
it
does
everything
and
it's
it's
the
elephant
that
does
everything
it's
like.
If
they
each
did
their
specific
thing,
they
do
one
thing
and
they
do
it
well,
then
people
could
run
multiples
of
them
and
if
you
enable
all
three,
then
you
effectively
have
what
state
history
does
today
correct
and
I.
A
D
D
It's
amazing:
how
discussing
the
note
types
you
know
generates
all
these
other
issues,
yeah
right.
Well,
it's
the
reason.
We've
run
so
many
different
nodes.
I
mean
that's
just.
Why
do
I
have
that
one?
Because
of
this,
why
do
I
have
a
deep
mind
and
a
state
history?
Luckily,
I
don't
run
trace
history.
D
E
B
D
D
E
D
B
B
Yeah
and
I
think
it's
worth
I
think
this
is
purposefully
General.
Maybe
because,
like
you
know,
I
could
imagine
you
processing,
just
just
history
related
to
your
own
contract.
I
could
imagine
you
you
know
having
a
general
purpose.
History
API,
like
you
know,
I,
could
imagine
listening
like
a
pub
subhub.
You
know
interface
for
these
things.
D
And
there's
a
lot
of
apps
that
don't
even
store
any
of
the
data
they
really
just
kind
of
listen
for
what
they
want.
Then
they
have
to
store
a
little
bit
of
data
to
handle,
for
you
know,
logic
and
all
of
that.
Okay,
that's
another
thing.
You
know
I
mean
you're
talking
about
a
publisher,
it's
like
here's
everything
I
got
if
it
Forks.
Ultimately,
the
consumer
has
to
go.
Oh,
she
had
already
seen
that
block
number.
Let
me
take
a
step
back
and
handle
it.
You
know
what.
E
D
Lot
of
time,
at
least
that's
an
issue
on
State
history,
I
assume
I
mean,
is
that
applied
to
the
other
two
as
well.
I
mean
more
as
the
publisher.
It's
just
sending
out
here's
a
block,
even
though
it
already
sent
out
a
block
that
it
now
has
to
go
back
and
be
like
whoa.
Everybody
else
says
no
I
mean
I
would
assume
it's
a
real
time.
D
D
B
D
Type,
it
could
be
used
for
history
or
it
could
just
you
know
if
you
advance
a
notified
actually
or
something
you
know,
I
mean
in
that
aspect
the
way
I
kind
of
see.
It
is
that
term
that
I've
been
there
to
fire
I
mean
they
don't
care
about
what
happens
more
than
a
couple
blocks
ago.
All
they
care
about
is
figuring
out
what
they
need
to
figure
out
at
the
current
time
and
moving
on
past
it
that's
an
event
Notifier,
it's
just
that's
the
only
websocket
or.
C
D
People
do
is
constantly
smash
the
API
and
say:
did
that
block?
Have
it
did
that
block?
Have
it
did
that
block
happen,
yep
correct,
that's
what
I
mean
you
don't
want
a
whip
socket
and
you
want
to
rest
query
or
something
that's
the
way
they
smash
through
it.
But
we've
tended
to
say,
hey,
look.
You
really
need
to
have
a
websocket
to
subscribe
to
it.
Oh
well,
it's
not
you
know.
Not
only
do
you
have
to
use
a
websocket,
but
now
you
gotta
also
process
it
and
then
get
the
data
you
want
out
there.
D
B
D
E
D
A
All
right,
thank
you,
Brian,
so
yeah,
a
great
great
discussion,
I
suppose
we
still
have
more
to
carry
on
next
week.
So
we'll
we'll
do
that.
I'll
share
the
notes
and
the
recording
in
the
chat
as
soon
as
it's
available
so
have
a
great
day
and
get
your
Camelo
applications
in
today's
today
is
pomelo
season.
Five
kickoff
day
it's
it's
you're,
looking
to
raise
some
funds
good
opportunity
there
for
you.