►
From YouTube: Mina Community Node Working Group Meeting | 4.14.22
Description
The weekly Node Working Group session serves as a platform for the community, ecosystem partners, and the Mina Foundation to interact.
This meeting is a time to discuss the latest core protocol releases and for members to propose suggestions, raise issues, and provide and get feedback.
If any community members have questions or feedback on the latest 1.3.0 beta 5 release, please visit the #mainnet-block-producers channel on the Mina Discord: https://bit.ly/MinaDiscord
The issues discussed can be found on GitHub: https://bit.ly/NWG-issues
Chapters
0:00 —Intro & Preamble
2:01 —O(1) Labs - Andrew - GitHub issues updates and overview
3:08 — O(1) Labs - Nathan - inconsistent SNARK inclusion rate issue
5:54 — Q&A / Discussion
Rust implementation
Possible hardware requirements
Node Triage issue progress
Discussion on adding other topics, eg, SnarkyJS, to NWG sessions
QA-net and upcoming testing
Mina Protocol – the world's lightest blockchain
A
A
Here's
the
preamble,
an
old
working
group
session
is
a
time
when
members
come
together
to
discuss
and
collaborate
with
ecosystem
partners
and
the
media
foundation.
Topics
generally
discussed
include
the
latest
releases
node
operations,
other
technical
matters
related
to
the
protocol,
hello.
This
is
the
discretion
of
the
node
working
group.
A
My
name
is
john
robinson
and
I'm
the
community
operations
manager
at
the
media
foundation.
I'm
here
to
support
and
facilitate
these
sessions.
So
please
feel
free
to.
Let
me
know
if
there's
anything
I
can
do
for
those
watching
the
recording.
Later
you
can
ask
any
questions
you
have
in
either
the
mainnet
block
producers
channel
or
the
devnet
channel,
just
put
them
out
there.
You
can
ping
chris
f
or
andrew,
for
example,
and
we
can
add
them
to
the
agenda.
A
A
A
A
Yeah
great
thanks,
andrew
and
for
those
who
didn't
see
it,
there
was
well
there's
been
quite
a
few
bits
of
feedback
in
the
discord
in
that
on
the
1.3
release
and
yeah
people
are
really
quite
happy.
It
seems
with
the
stability
and
I'd
like
to
say
thanks
a
lot
to
all
you
guys
for
putting
in
all
the
work
on
that
and
yeah
making
it
really
really
stable.
Like
that
nathan,
you
mentioned,
you
might
have
some
updates
today,
too.
C
So,
just
to
summarize,
this
is
the
issue
that
jr,
washburn
and
other
community
members
have
brought
up
before.
If
you
go
on
to,
for
instance,
the
mainnet
block
explorer
you'll
see
a
series
of
blocks
back
to
back
with
zero
snark
work
included
and
then
a
couple
blocks
with
a
whole
bunch
of
snark
work
included,
and
this
is
not
exactly
the
most
ideal
behavior
for
moving
the
network
forward.
D
C
This
is
happening,
and
you
know
whether
or
not
it's
an
issue
we're
going
to
do
about
it.
So
I
went
and
recreated
the
same
issue
on
our
devnet
environment
and
collected
logs
from
there
and
did
a
little
bit
of
an
analysis.
I
met
with
deepti,
who
is
engineer
in
our
team,
who
primarily
maintains
that
part
of
the
code,
and
basically
our
understanding
of
the
problem
is
that
this
is
primarily
cause.
C
If
they
have
enough
transactions
to
require
them
to
include
any
snark
work
and
then
once
they
begin
the
algorithm
that
includes
snark
work,
they
will
include
as
much
snark
work
as
they
probably
can.
So
the
behavior
ends
up
being
that
once
one
producer
includes
a
whole
bunch
of
snark
work
because
it
was
able
to
free
up
a
whole
bunch
of
space
in
the
chain
and
a
lot
of
that
snark
work
was
free,
so
they
just
purchased
it
and
they
free
up
so
much
space
to
change
that.
C
So
many
block
producers
after
that
don't
have
enough
transactions
to
even
fill
up
the
space
that
was
made
available
by
the
first
person,
and
then
that
means
that
whoever
is
kind
of
at
that
tail
end
of
that
sequence
then
ends
up
having
to
do
more
work
and
pay
out
more
fees
than
the
other
block.
Producers
are
so
we.
C
Been
around
for
a
bit
that
we're
working
on
reviving
that
does
change
his
behavior.
It
changed
the
behavior
for
unrelated
reasons,
but
it
would
also
address
this
problem.
So
we're
looking
at
that
and
we're
hoping
we
plan
to
pick
that
up
sometime
before
the
incentivize
test
that
hopefully-
and
if
not,
we
at
least
plan
to
do
it
before
the
hard
fork
so
yeah,
that's
sort
of
the
update
there.
I
can
elaborate
on
that
more
if
people
need
more
information
on
that.
A
A
A
B
B
B
I
mean
we're
we're
trying
to
optimize
all
the
code
that
we're
you
know
well
we're
making
lots
of
optimizations
to
the
code
that
is
shared
between
you
know,
prefork
and
post
fork.
So
each
new,
you
know
successive
version
as
you've
seen
the
the
hardware
requirements
get
lower
and
in
parallel
to
that,
the
new
proof
system
and
all
the
changes
that
are
going
to
come
along
with
the
fork,
may
even
bring
further
optimizations
to
get
hardware
usage
down.
B
D
B
E
B
F
Yeah,
hey
everybody,
I
guess
I'd
be
curious.
I
saw
us
heard
some
discussion
about
this
rust.
Meena
note
I'm
loosely
involved
in
that
I
guess
there's
any
question
yeah.
It
is
in
development
kind
of
as
a
separate
thing,
not
part
of
the
meena
daemon.
I
do
have
some
updates.
I
guess
on
issues
that
were
reported
by
the
community.
I
don't
know
if
you
guys
have
had
the
chance
to
discuss
that
yet,
but
maybe
we
can
talk
about
that.
A
little
bit.
A
F
A
F
C
C
This
doesn't
happen
in
practice
if
there
are
a
lot
of
transactions
in
the
network
because
they
have
slightly
different
views
of
the
mempool,
but
occasionally
this
can
happen
where
they
both
have
the
same
view
of
the
mempool
and
they
both
produce
the
exact
same
identical
block.
So
what
would
happen
previously
is
that
daemon
didn't
expect
the
same
block
to
ever
be
entered
into
the
same
data
structure,
and
so
it
would
crash
when
that
happened.
C
A
D
C
F
Yeah
and
the
other
one
that
I
was
hoping
to
provide
a
small
update,
one
was
on
something
that
nathan's
been
investigating
the
snark
work
conclusion.
I
don't
know
if
you
guys
have
had
a
chance
to
talk
about
that
before
I
joined
but
nathan.
I
think
you
did
some
investigation,
maybe
there's
something
small
that
we
can
share
with
the
community.
C
F
Okay,
okay,
great
and
then
the
next
thing
is
yeah.
We
are
going
to
kind
of.
I
need
to
prune
this
board
a
little
bit
because
there
has
been
like
so
many
stability
fixes
in
the
last
stable
release,
so
we're
going
to
like
move
some
of
these
needs
triage
where
appropriate
out,
but
that
was
the
main.
The
number
one
on
low
priority
was
the
main
thing
that
has
been
delivered
yeah.
So
that's!
That's
all
for
me.
A
D
I
think
mentioned
that
you
know,
since
we,
since
we
have
enough
time
for
other
topics,
I'm
wondering
whether
we
could
get
an
occasional
updates
on,
for
example,
slickyjs
and
proof
systems,
and
you
know
once
per
month
or
maybe
every
two
weeks
to
get
people
like
gregor
or
maybe
david
to
to
give
the
community
some
updates
on
those
aspects,
because
you
know
these
videos
are
released
to
the
public.
So
there's
no
confidentiality
issue,
I
think,
would
that
be
possible?
I'm
just
wondering.
A
Yeah,
I
think
finally,
so
that
was
a
great
suggestion.
Anyone
had
about
adding
different
topics
now
that
well,
I
guess
everyone's
been
working
so
hard
on
the
stability
and
it's
come
along
so
well,
there
is
a
section
on
there.
It
does
take
a
little
bit
of
time
to
organize
different
people
with
the
schedules
and
that,
but
it's
something
definitely
like
to
look
into
for
sure.
A
A
Why
don't
you
put
something
down
at
the
bottom
of
the
agenda?
There's
an
actual
section
we
made
where
you
can
add
these
kind
of
questions
or
issues
or
topics
for
discussion
and
what
I
can
do.
I
can
also
ask
some
other
people
to
come
in
and
and
discuss
them,
and
it
is
possible
that
we
could
make
up
a
separate
call
if
need
be
too,
but
first
start,
maybe
just
add
something
down
there.
That's
a
great
one.
A
F
One
of
the
chief
ones
is
the
renaming
change
from
snaps
to
zk
apps
I'll,
be
publishing
the
release
notes
a
little
bit
later
today
that
catalog
all
the
different
things
that
went
in
there
and
yeah.
If
you
guys
want
to
get
involved,
please
let
john
know
or
post
in
the
devnet
or
one
of
the
main
channels
and
you'll
get
you
added
to
the
qa
task
force.
A
A
A
A
All
right,
we'll
finish
off
the
call
now,
if
you'd
like
to
stay
around,
please
hang
around
for
a
chat.
If
not
well.
Thank
you
very
much
for
your
time
and
you
guys
have
a
great
week
out
there.
Oh
and
sorry
before
we
go
there's
one
more
thing:
it's
very
likely
that
next
week
we
won't
be
able
to
have
a
note
working
group
session.