►
From YouTube: Node Operator Roundtable - June 14th, 2023
Description
The Node Operator Roundtable discusses instrumenting nodes for improved data gathering and developer experience, and discusses experimenting with novel solutions using the fire hose substream and upcoming advancements in Antelope software development.
00:00:00 Introduction
00:00:10 Software Updates
00:03:14 Decoupled Instrumentation Feasibility
00:15:06 Serialization and Deserialization
00:20:44 Experimenting with Novel Solutions
00:26:30 Antelope Firewall
00:31:00 Using Alternate Languages
00:54:02 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
B
B
So
that's
it
in
the
way
of
updates.
As
far
as
agenda
for
today,
I
think
my
my
fallback
here
is
that
we
can
go
back
to
the
node
types
discussion
which
we
haven't.
We
haven't
really
moved
on
in
a
few
weeks
now,
but
before
we
go
there,
I'd
like
to
do
some
sort
of
open
floor
agenda
building
here
to
see
if
there
are
any
topics
that
people
feel
are
are
more
time
sensitive,
that
we
should
cover.
First.
D
B
Yeah
to
talk
about
it,
so
this
is
decoupled,
instrumentation
feasibility,
which
I'll
share
a
link
here,
you
know
spoiler
alert
as
Corbin
mentioned.
We
did
postpone
this.
For
now.
We
we
have
a
plan
for
sort
of
the
next
thing
we
want
to
look
into
when
we
decide
to
revisit
this,
but
basically
what
so
there
there's
a
number
of
to
explain
the
impetus
for
for
why
we
were
looking
into
this
in
the
first
place,
there's
a
number
of
sort
of
logging
based
sort
of
representations
of
data.
B
B
B
A
B
More
sort
of
parallelization
of
effort
right,
like
people
different
different
tools
of
that
nature,
could
sort
of
all
coexist
as
as
separate
libraries,
for
example.
Another
thing
is
just
you
know,
just
a
cleaner
code
base.
It
keeps
it
keeps
instrumentation
stuff
out
of
a
code
base.
There's
also,
you
know
performance
consideration
of
just
simply
not
having
those
things
in
there
at
all.
If
you're,
if
you
don't
need
them,
you
know
so
all
of
those
things
were
kind
of
in
our
minds.
B
What
we've
done
so
far
is
the
illustrious
Kevin
heidner
spent
some
time
doing
what
we
call
a
spike.
It's
just
sort
of
a
quick
exploration
into
what
this
might
look
like
and
and
and
the
output
of
that
was
sort
of
a
informal
proposal,
if
you
will
on
on.
If
we
wanted
to
proceed
with
this,
what
might
it
look
like,
ultimately,
where
we
landed
with
this?
Was
that
the
the
reasons
for
doing
it
are
still
there
right?
So
we
we
will
likely
come
back
to
this
at
some
point
in
the
future.
B
However,
you
know
there's
we
decided
that
the
the
gains
were
likely
to
get
at
least
out
of
this
approach
for
now
versus
the
effort
involved.
Just
you
know
the
the
cost
benefits
balance
wasn't
really
there.
Yet
what
we
are
considering
for
the
future
is
looking
at
traces
as
in
some
ways
solving
the
same
issues
and
and
therefore
investing
in
augmentations
to
the
what's
provided
by
traces
to
be
able
to
fill
these
needs.
B
D
D
Hey
I
want
all
the
actions
for
a
specific
contract,
and
then
you
have
the
processing
side
that
only
receives
the
data
that
you
want
to
receive
yeah.
So
let's
something
I
just
wanted
to
mention
as
as
an
idea,
and
it
wasn't
even
that
hard
to
build
library
and
to
do
this.
This
kind
of
abstraction
allowing
us
to
pass
method,
pointers
and
data
pointers
between
the
the
consumer
and
producer
and
reading
the
chain
state
is
something
we've
also
thought
about,
mostly
because
currently
scaling
the
apis.
D
It's
hard.
You
always
have
to
provide
more,
no
deals.
Instances
if
you
want
to
scale
the
the
number
of
chain,
API
requests
you
can
handle,
and
if
you
had
this
this
this,
if
you
would
be
able
to
read
directly
from
change
date,
you
could
just
build
your
own
caching
layer
and
whatever
kind
of
load,
balancing
thing
around
it
yeah.
E
Yeah
I
think
that's
a
lot
of
really
good
information.
I
will
mention
you
know
in
4.0
we
do
have
the
ability
to
all
the
chain.
Api
read-only
calls
like
category
roll
and
those
are
all
multi-threaded
so,
but
you
can
give
it
as
many
read
threads
as
you
want,
and
that
should
be
able
to
scale
up
without
having
to
add
additional
notice.
D
Want
I'm
always
thinking
a
lot
about
the
the
gaming
area
and
I'm
always
thinking
about
how
to
integrate
or
how
to
connect
no
deals,
and
maybe
gaming
servers
or
history
Solutions
made
for
gaming
and
always
thinking
about
low
latency
and
the
ability
to
build
New
Deals
as
library
and
to
integrate
it
directly
into
your
game.
Server
to
be
able
to
instrument
it
or
to
yeah
and
orchestration
I
think
could
long
term
be
a
major
benefit
thinking
about
gaming
servers
and
how
the
the
gaming
word
currently
looks.
D
I
could
see
not
sure
if
any
one
of
you
knows,
but
there
are
these
these
tools,
their
software,
that
allows
you
to
spin
up
tons
of
different
gaming
servers
for
tons
of
different
games
with
just
a
few
clicks
and
that's
something
that
gamers
today
already
do,
and
they
are
used
to
do
that
and
I
always
imagine
that
in
the
future
you
can
say:
hey
I,
want
to
spin
up
this
game
server
running
a
specific
game
which
integrates
an
audios
and
and
you'll
say.
Oh
Elite,
node
and
kind
of
runs
its
own
blockchain
on
this
game.
B
B
D
E
You
know
the
a
lot
of
software
developers,
whether
they're,
you
know
interface,
one
interface
via
Java
or
whatever
other
language.
You
know
the
proper
boss
just
makes
that
so
much
easier
as
opposed
to
having
to
implement.
You
know
this
proprietary
if
you
will
ft
serialization
now
at
this
point,
you
know,
there's
already
a
lot
of
existing
libraries
that
do
provide
that,
whether
it's
go
or
python
or
you
know-
that's
been
built
up
by
the
community
over
time.
B
A
B
Things
that
are
this,
this
is
kind
of
just
restating
the
read-only
transactions
piece,
but
with
read-only
transactions
there's
a
lot
more
parallelization
like
you
know,
multi-threading
that
happens
that
API
the
API
plug-in
benefits
from
and
is
related
to
this
in.
In
that
the
whole,
you
know
the
whole
sort
of
top
to
bottom,
it's
multi-threaded,
which
of
course
means
that
you're,
serialization
and
deserialization
isn't
happening
on
that
main
thread.
D
Yeah
to
me
it's
just
the
the
the
closer
the
piece
of
software
is
to
the
no
deals
instance,
the
less.
It
makes
sense
to
me
to
do
this.
Theorization
the
serialization
yeah
I
mean
you
should
think
about
how
much
data
is
converted
to
hex
and
then
converted
from
hex
to
Binary
every
second
second,
and
how
much
work
is
done.
That
not
really
needs
to
be
done
to
me
that
just
doesn't
make
much
sense.
Looking
at
the
possible
the
possible
bandwidth
of
data
and
latency.
A
E
A
D
That's
it
from
my
my
side.
We
were
probably
at
some
point
with
a
lot
a
bit
more
work
into
this
interop
solution.
Building
new
gears
as
library
and
integrating
this.
This
interface
and
I
will
just
tell
you
and
then
we
can
can
discuss
it
again
and
then
we
see
we
see
also
the
the
performance
differences
and
all
that.
E
Yeah
I
I
think
we
would
be
open,
I'm
speaking
out
a
turn
here,
obviously,
but
I
think
we'd
be
open
to
a
PR
to
that
effect.
You
know,
as
long
as
that
interface
has
been
implemented
by
the
existing
deepmind
logger
so
that
you
get.
You
know
the
same
behavior
having
that
interface
at
in
there
available
as
part
of
their
code.
I,
don't
I,
don't
see
any
reason
why
it
wouldn't
just
take
that
yeah.
B
If
you
could
reach
out
to
me,
because
I'd
love
to
sort
of
look
over
your
shoulder
and
get
a
get
a
good
understanding
of
of
what
you're
doing
like
sort
of
unexpected
stuff
that
you're
doing
like
some
of
the
stuff
that
Oregon
has
been
sharing
here
about
solutions
to
speeding
up
notes
for
a
specific
use
case.
Like
you
know,
I'll
I'll
be
reaching
out
to
Corbin
to
to
learn
more
I.
Think
it's
really
interesting.
But
understanding
was.
D
D
That
that
that
that
that
allow
this,
this
kind
of
of
software
is
limited.
You,
for
example,
you
can't
just
use
JavaScript,
because
you
can't
access
memory
the
same
way,
but
for
for
for
this
kind
of
higher
leveling,
which
is
go
python,
C
plus
plus
for
sure
C
sharp,
there's
a
ton
of
languages
that
support
this.
D
D
D
I
mean
it's
a
little
a
little
crazy
in
the
the
idea
of
doing
Collision
detection
on
chain,
but
thinking
long
term
and
thinking
of
how?
How
okay
could
we
differentiate
from
other
chains?
How
can
we
add
functionality
needed
for
specific
businesses
and
industries?
This
could
be
something
I
think
yeah
and
there
are.
D
There
are
a
few
more
interesting
data
structures
that
could
be
added
and
would
bring
a
benefit
yeah
and
doing
all
this
in
a
smart
contract.
I
mean
you,
you
theoretically,
could
add
AABB
trees
within
the
smart
contract
and
she
realized
deserialize
them
somehow
install
them
just
in
a
multi-index
table
that
again
comes
with
a
lot
of
performance
over
at
the
end.
F
C
Don't
know
she's
there,
yeah
and
I
actually
said
to
Matthew.
Probably
should
it'll
be
interesting
to
swing
by
this
discussion
to
talk
about
it
a
bit
we
spoke
about
it
like
two
months
ago
and
I
believe
there
was
actually
a
grant
and
that's
what
you
guys
are
building
now,
but
it
seems
really
really
valid
to
bring
it
up
with
the
guys
here.
Maybe
just
I
mean
I
can
I
can
try
and
give
a
highlights
of
what
it
is
might
be
interesting
for
a
discussion
one
of
the
days.
C
It
might
also
end
up
actually
terminating
SSL
requests
and
actually
being
like
the
the
load
balancer
itself,
but
the
real
value
is
that
it's
got
like
application
visibility,
meaning
like
it
understands,
accounts
and
contracts,
and
you
can
create
policies
for
load,
balancing,
two
and
rate
limiting
based
on
what
contract
or
account.
This
is
in
those
contracts
and
yeah
it's
it
seems
pretty
awesome.
There
should
be
some
software
that
we
can
test
like
in
the
next
month
from
how
I
understand
it,
but
apparently
it
was
an
enf
Grant.
C
We've
definitely
spoken
about
something
before
we
discussed
petronius
at
one
point
like
hey
I,
remember
we
had
petroneous
or
whatever.
So
this
is
you
know
some
of
that
functionality
and
way
more.
You
know
if
we
had
to
have
a
contract,
that's
getting
the
snot
beaten
out
of
it
on
you
know
we
can
limit
it
on
on
the
APR
based
on
Source
address
account,
that's
actually
interacting
with
the
contract
Etc.
C
You
know,
and
a
few
other
things
and
they're
building
it
so
that
there's
going
to
be
some
templates
that
we
can
use
but
you'll
be
able
to
construct
your
own
like
Json
file,
where
you'll
be
able
to
you
know,
get
it
to
do
certain
things,
depending
on
whatever
criteria,
what
it
picks
up
in
the
contract.
So
I
thought
that
was
pretty
cool,
very
cool.
C
D
E
C
B
D
Compiling
c-sharp
code
to
webassembly
smart
contracts
that
can
be
used
with
with
leap
no
success
yet,
but
the
the
Microsoft
team
is
making
a
lot
of
progress
when
it
comes
to
Wazi
and
webassembly
and
binaries
are
getting
smaller
and
smaller.
The
big
problem
still
is
a
lot
of
the
net
runtime
there's
the
garbage
collector.
There
is
exception
ending
and
all
that
adds
a
lot
of
overhead,
but
it
seems
like
over
the
next
six
to
12
months.
D
Again,
thinking
about
game
development,
game
developers
either
write
their
code
in
C,
plus,
Unreal,
Engine,
C,
plus
plus,
or
in
C
sharp
Unity
3D
and
today,
most
of
the
web
3
gaming
ecosystem
is
done
in
in
unity.
It's
like
80,
90
percent
or
so
of
the
of
the
projects
are
done
in
unity
and
I.
Think
being
able
to
compile
C
sharp
to
something
that
can
run
in
the
in
the
EOC
VM
at
esvm
again
could
be
a
great
great
benefit
for
for
adoption.
D
I
mean
every
developer
in
this
call
knows
how
it
feels
if
you
are
enthusiastic
and
and
if
you
like,
a
specific
language
and
you're
used
to
use
it
in
a
specific
way
and
then
as
a
c-sharp
developer,
having
to
write
C
plus
plus
for
many
C
sharp,
not
for
me,
but
for
many
C
sharp
developers.
It's
a
pain
same
for
JavaScript
or
typescript
developers,
right
yeah,
let's
at
least
something
I'm
I'm
following
and
from
time
to
time,
giving
a
try.
D
Yeah
and
another
thing
I'm
I'm
at
least
thinking
about
is:
could
we
I
mean
basically
yeah?
Could
we
make
no
deals
more
like,
like
the
like
a
state
machine
for
for
game?
I
mean
it's
basically
already
a
state
machine
right,
how
a
block
is
produced
and
all
these
different
steps
in
there,
but
more
estate
machine
for
gaming,
where
you
not
only
I
mean
currently,
you
have.
We
have
the
on
block
action
in
every
block,
I
think
at
the
beginning
or
at
the
end,
and
if
we
had
more
of
these.
D
I
mean
things
like
again:
it's
crazy
many
many
will
say
it's
crazy
to
do
that
on
a
blockchain,
but
things
like
like
movement
moving
something
continuously
moving,
something
if
it's
just
just
a
ball
rolling
down
a
road
right,
you
have
to
constantly
move
it
with
every
whatever
block
time
we
have
500
milliseconds.
We
want
to
move
it
two
meters
and
having
a
state
machine
that
moves
this
ball.
Every
500,
milliseconds
and
I
mean
that's
basically
how
every
every
game
engine
today
Works.
They
always
have
these
State
machines.
D
C
You
get
your
15
minute
allotment
and
you
had
to
move
a
ball
like
it
was
in
the
guards
like
loft
or
something,
and
he
had
to
like
move
a
ball
into
like
a
hoop
to
win
a
bras
type
of
thing,
and
it
was
like
you
know.
The
logo,
like
you
know,
40
years
ago,
where
you
had
to
go
left
90
degrees
forward,
10.
It
was
that
kind
of
stuff,
but
they
were
all
just
actions.
D
Then
you
have
much
more
frequently
you
have
actions,
then
your
ball
is
moving
much
more
smoothly
and
then
you
can
do
the
rest
in
your
front,
end
and
just
add
frames
in
between
and
then
at
some
point,
I
think
you
could
have
something
that
feels
like
a
completely
normal
gate.
It's
just
running
on
a
blockchain
but
yeah
again.
B
B
B
Yeah
I
think
I
think
there's
there's
there's
interesting
things
to
explore
there
as
well,
but
I
am
curious.
One
thing
that's
crossed
my
mind.
Is
it
would
be
fun?
This
is
more
of
like
a
Communications
and
marketing
kind
of
thing.
You
know:
we've
just
we're
celebrating
five-year
anniversary,
it'd
be
cool
to
do
a
sort
of
a
look
back
of
the
cool,
crazy,
weird
things
that
people
have
built
on
EOS
or
other
Antelope
chains.
You
know!
B
G
That
will
work
correct.
So,
if
you
wanted,
you
know,
pull
history
data
directly
into
a
browser
and
build
the
spot
ticker
or
something
go
ahead.
Obviously
some
things
won't
work
really
well
in
the
browser,
because
you
know,
if
you
need
to
actually
capture
the
results
and
not
wait,
you
know
20
minutes
for
it
to
calculate
so
you
know
you
have.
A
G
That'll
work
on
a
browser
right.
It's
just
that
this
is
the
data
volume
you
need
to
practice.
You
need
to
process
in
order
to
get
the
results
right
so,
but
yeah
yeah
this.
This
is
coming,
so
you,
you
know,
run
it
directly
in
a
browser
or
put
it
in
a
sync
store
it
somewhere
or
do
something
with
it.
The
student
Foss
team
did
a
test.
G
They
took
a
uniswap
V3
and
they
loaded
it
into
a
graph
node
in
20
hours,
using
substrings
and
a
bulk
import
process
into
the
graph
database,
and
it
used
to
take
two
more
seriously
argument
or
yeah
yeah
exactly
two
two
plus
months.
So
you
know
that
that's
a
major
change
in
you
know,
developer
usability,
so
so
yeah,
so
we're
spending
a
lot
of
time
on
this.
G
This
is
a
as
I
said,
a
little
more
near
term
than
what
you
were
talking
about
earlier,
but
we're
really
excited
to
have
this
ecosystem
Antelope
support
the
same
as
ethereum
or
you
know
those
other
blockchains
where
we're
at
the
same
level
of
support.
So
we're
not
the
second
classes,
which
is
excellent.
D
D
G
It's
too
slow
agree,
but
the
the
bulk
of
the
community-
that's
really
going.
Oh
over,
you
know,
substrings
is
used
to
you,
know
12
second
block
times
on
ethereum
yeah
sure
right.
So
so,
oh
you
get
the
Block
in
one
second
wow
fantastic.
You
know
yeah
yeah,
that's
a
big
difference
because
you
have
to
sit
there
and
wait
for
the
ethereum
block
to
happen
anyway.
So
you
know
the
the
substrings
overhead
is
this.
G
You
know
not
significant
sure
but
yeah,
but
for
for
the
envelope
blockchains
yeah
I
mean
it
it
there's
I,
don't
know
if
anybody's
done
any
specific
testing
on
that.
Maybe
we
can
try
doing
it
a
bit
later,
but
yeah.
It's
not!
It's
not
going
to
be
good
enough
for
for
what
you
were
talking
about
earlier.
F
And
when
there's
a
transaction
propagation,
which
is
like
not
like
at
the
beginning
right
like
how
how
much
time
it
takes
to
push
the
transaction,
how
much
time
it
takes
to
get
loaded
into
a
block,
yeah
and
then
propagate
to
the
history
solution
and
then
deepmind.
So
maybe
the
Deep
Mind
to
some
stream
is
actually
really
fast
but
like
it
takes
two
seconds
to
get
to
go
through
the
whole
flow.
So
I
know
that
the
evm
is
like
as
well
like.
F
G
D
G
G
You
know
so
yeah
represent
the
EOS
evm
as
an
ethereum
like
blockchain,
so
that
you
get
a
block
that
looks
like
the
other
ethereum
block.
So
if
you're
going
across
different
evm
chains,
then
you
get
a
fire
hose
substitutions.
That
looks
like
those
and
you
don't
have
to
do
all
this
weird
decoding
bits.
So
I
think
both
options
are
are
on
the
table.
So
I
know.
E
I
think
we
didn't
I
think
that
on
the
silkworm
RPC
implementation,
as
opposed
to
directly
on
on
the
implementation,
is
that
what
you're
thinking,
yeah,
yeah,
yeah,
okay,
cool,
yeah,
it'd,
be
it'd,
be
great
to
I.
Guess
have
both
available
right
where
you
can
yeah,
you
know
the
native
one
is
cool
in
my
mind.
You
know,
because
you
get
it
like
directly
from
the
from
the
horse's
mouth.
If
you
will-
and
you
can
correlate
it
directly
with
the
blocks
that
the
ethereum
transaction
is
in,
which
is
you
know
something?
F
Yeah,
so
one
of
the
things
is
also
like:
there's
transactions
on
EOS,
which
you
can
maybe
replicate
into
ethereum
transactions,
but
the
best
would
be
to
take
directly
from
you
know
the
silkworm
implementation,
and
that
way
you
get
a
one-to-one
ethereum
block
that
way.
If
developers
build
ethereum
substream,
you
know
indexing
and
sort
of
tools.
Well,
then,
the
evm
works
one
to
one
and
it's
not
a
master
that
is
eos
block.
F
That
way,
it
kind
of
you
can
have
like
Mass
adoption
of
the
fire
hose
implementation
for
any
evm
without
any
custom
instrumentation.
Of
course,
the
custom
instrumentation
would
be
more
data.
Rich
you'd
have
more
data,
but
if
you
just
want
to
get
it
started,
there's
going
to
be
sort
of
a
light
fire
hose
implementation
for
evm
and
that's
I,
think
I,
don't
know
if
it's
still
on
a
priority
for
them
or
you're,
not
I.
E
F
E
G
Information
yeah,
the
the
issue
that
needs
to
be
solved.
There
is
the
developer
experiences
it.
How
do
you
know
you're
on
the
light
version
of
fire
hose
or
the
full
version,
and
then
hop
view?
What
happens
when
you
try
to
migrate
or
whatever
so
there's
there's
some
weird
things
that
need
to
be
solved
there
to
make
sure
the
developer
experience
is
reasonable,
but
I
think
if
they
can
solve
those
kind
of
questions,
then
that
would
enable
this
kind
of
tool
to
be
built.
G
It
change
history
right
or
every
table.
You
know
you
only
get
yeah
database
operation
right.
You
only
get
it
at
the
Block
Level.
So
the
only
way
to
get
that
is
to
have
like
an
instrument,
it's
a
quorum.
That
has
one
quote
about
definitions
and
all
that
fun
stuff
right,
exactly
which
could
be
done
as
well
right.
If
somebody
wanted
to
spend
the
time
at
the
instrumentation
into
software
and
then
away,
we
go.
G
Actually
yeah
so
go
ethereum
is
done
by
Australian.
Fasting
go
Antelope
is
done
by
US,
based
on
the
original
work
done
by
the
strange
team
to
make
it
work
for
mandelion
movie,
yeah
Mandel
leap,
whatever
all
those
changes
and
to
keep
up
with
the
latest
fire
hose
stuff,
because
the
the
original
stuff
was
done
for
the
fuse
and
there's
been
a
lot
of
changes.
Since
then,
there's
also
going
to
be
work
for
those
in
the
ethereum
community
who,
like
Aragon,
there's
work
to
instrument
the
Aragon
binary.
A
B
A
Thank
you,
Brian
yeah,
this
one's
hot,
the
Press
I,
think
just
published
like
two
hours
ago.
So,
if
you
haven't
I'm
sure
you
haven't,
I
haven't
even
yet
check
it
out,
looking
forward
to
to
watch
it
myself
but
very
relevant
to
the
discussion
absolutely
but
anyways.
Yes,
thank
you
great
great
conversation,
folks
and
we'll
see
you
all
next
week.