►
From YouTube: Eth2.0 Call #54 [2020/12/17]
Description
A
A
A
There
are
some
minor
features
that
are
being
worked
on
that
we
expect
to
come
out
in
something
of
like
a
minor
hard
fork
early
mid
next
year.
The
actual
discussion
of
what's
going
to
go
in
there
I'd
say:
let's
wait
until
january,
we
can
spend
some
time
making
it
kind
of
clear
what
the
intentions
are
and
we
can
debate
and
go
back
and
forth
a
little
bit.
A
I
think
the
low-hanging
fruit
here
are
a
little
bit
of
accounting
reform
on
how
attestations
and
things
are
stored
in
state,
adding
a
sync
committee
or
light
client
sync
committee,
which
reuses
some
of
the
generally
similar
committee
functionality
both
on
the
networking
level
level
and
in
the
in
the
spec
to
add
a
white
client
first
support
and
some
other
small
stuff.
But
again,
I
think
our
time
will
be
better
spent
formalizing
some
of
that
stuff.
Writing
it
down
getting
people
up
to
speed,
and
then
we
can
discuss
it
in
january.
B
Should
interrupt
in
just
those
specific
issues
like
there
are
github
issues
and
pull
requests
and
that
you
specs
that
you
can
look
at
already
so
on
the
accounting
reform
stuff,
if
you
just
go
into
the
polls
section
of
each
use,
specs,
so
the
the
most
recent
and
recent
two
from
myself.
I
forget
the
numbers,
but
one
says
like
accounting
reform
and
the
other
says
quotient
reform,
or
something
like
that
highly
recommends
for
client
developers
to
look
at
them
and
at
least
familiar
familiarize
yourself
with
the
proposals
and
comments.
A
Right
and
some
of
that
in
there
moves
some
of
the
state
accounting
to
the
way
it's
generally
optimized
on
epoch
transitions
anyway.
So
I
think
this
would
be
a
net
benefit,
helps
for
things
like
empty
pop
transitions
and
stuff,
which
are
currently
probably
a
dos
vector
cool,
so
ongoing
work.
There
there's
also
to
make
this
testing
a
little
bit
more
sustainable.
C
Not
much
crashes
lately,
which
is
good.
I
guess
we
had
to
fix
our
fuzzers
after
a
few
client
updates.
Messed
them
up
still
have
one
small
issue
with
hong
kong's:
the
mutation
based
fuzzing
engine,
not
the
structural
one.
It's
spitting
out
way
too
many
false
positives
to
be
useful,
so
we
need
to
basically
implement
some
timeouts
to
give
it
enough
time
to
initialize
all
the
clients
but
yeah.
It's
been
good.
We've
been
working
with
parry
on
deploying
the
fuzzers
to
the
aws
infrastructure.
D
D
A
E
A
F
We've
modified,
eth1
genesis,
block
search
to
be
more
tolerant
of
missing
historical
blocks,
we've
reduced,
we
can
say
backing
tree
heat
consumption
and
we
significantly
sped
up
as
a
seed
serialized
in
the
serialized
and
we
fixed
the
bug
which
caused
eco
to
produce
invalid
at
the
station
aggregates.
That's
about
it.
A
G
Hey
guys,
terence
here
so
we've
added
a
database
backups
at
runtime
for
both
and
validate
validator
client.
We
also
support
team
reading
graffiti
from
file,
and
this
is
for
the
validator
side,
and
this
was
a
highly
requested
user.
We
have
peer
scoring
enabled
by
default,
we
update
it
to
golan
1
15.6
and
with
disk
io
for
validator
client,
and
this
results
in
safer
testage,
a
safer
tester
slashing
protection,
which
is
great.
G
A
C
C
I
think,
like
a
lot
of
people,
there's
been
some
f1
client
issues,
so
geth
works
seemingly
and
seems
to
work
really
well,
but
everything
else
seems
to
struggle.
So
we
we
also
added
an
f1
fallback
node
and
a
while
ago,
and
we
also
now
have
a
manual
flag
for
users
to
purge
their
ethernet
cache
for
dodgy
clients.
We
simplified
the
beacon,
lock
files
we're
now
using
os
locks.
C
We
almost
completed
the
standard,
http
api,
the
service
and
events
are
implemented.
Now
I
went
and
corrected
some
light
attestations
we've
been
testing
and
analyzing
gossip
cell
data
metrics
and
scoring
so
we
found
a
little
discrepancy
in
the
expected
message,
propagation,
which
will
be
corrected
very
soon
in
the
future.
Pr
and
yeah
we're
currently
working
on
reducing
our
block
proposal.
E
We
added
also
a
new
performance
scoring
so
that
you
can
check
if
your
system
can
keep
up
with
the
small
requirement
of
the
if
to
chain,
and
also
importantly,
we
fixed
some
a
bug
where
we
didn't
fully
aggregation.
We
received
and
we
forwarded
them
to
the
network
and
we
ended
up
getting
bad
score
and
we
also
fixed
issue
in
gossip
sub,
which
led
to
a
slightly
worse
attestation
effectiveness.
E
So,
right
now
we
are
focusing
on
a
couple
of
performance
bottleneck.
One
is
disk
io.
So
when
we
we
have
some
io
when
we
do
attestational
block
proposal
that
we
would
like
to
reduce
and
accelerating
state
transition
via
having
something
called
a
state
diff.
Instead
of
storing
the
wall,
the
wall
state
and
lastly,
multi-threading
that
we
plan
to
have,
we
have
the
primitives
done
and
we
plan
to
refactor
or
verify
benefits
from
multithreading
at
two
different
levels
and
for
maybe
three
weeks
from
now.
E
H
Hello,
everyone
so
past
few
weeks
we
turns
out,
we
hadn't
implemented
the
api,
the
standard
api,
but
we
implemented
those
two
thing
to
end
points
we
finally
got
on
implementing
and
integrating
the
bls
batch
verification
which
really
helped
helped
us
and
we've
just
been
going
going
through
profiling,
writing,
beacon,
node
and
fighting
finding
low
hanging
fruits.
Some
things
as
simple,
as
you
know,
like
in
lib
p2p,
getting
piers
in
in
jsp
is
kind
of
a
it
takes
a
while.
So
just
doing
our.
H
Yeah
sorry
was
last
thing:
you
heard
bls
batch
verification
profiling,
how
to
get
peers
right,
so
we're
just
doing
less
to
try
to
get
some
final
things
together
that
are
really
stopping
us
from
having
a
responsive,
beacon,
node.
All
the
time
and
we've
decided
to
cut
cut
releases
every
two
weeks.
So
we're
just
going
to
do
like
a
really
that
kind
of
release
schedule
so.
H
Yes,
so
it
works,
I
will
say
currently,
so
you
could
pull
it
down
from
either
master,
build
it
or
from
npm.
But
one
thing
it
will
like
kind
of
pause
every
few
minutes,
but
it
will
it
will.
It
will
stay
on
the
head,
but
it
will
not
be
responsive
at
all
times,
so
we're
working
through
those
last
things.
A
A
A
B
I
think
one
really
important
thing
is
that
you
need
to
have
a
library
that
exposes
bls
operations
so
multiplication
and
addition
being
the
most
important
ones.
And
ideally
you
want
this
fast
linear
combination,
some
aka
multi-exponentiation,
which
basically
just
takes
a
whole
bunch
of
points
and
a
whole
bunch
of
coefficients
multiplies
each
point
by
the
coefficient
sums
them
all
up
and
gives
you
the
output.
B
Basically
there's
you
know,
optimized
ways
of
doing
that
that
are
potentially
up
to
something
like
10
times
faster
than
for
for
large
inputs
than
doing
it.
The
kind
of
naive
way.
So
if
you
have
libraries
that
do
those
things
saying,
if
you
don't
have
the
fast
linear
combinations
that
you,
then
you
could
also
just
code
it
yourself.
So
if
you
do
have
things
it's
actually
not
that
hard
and
so
making
a
academic
commitment
for
a
piece
of
data,
just
what
it
really
means.
It's
a
step.
B
You
have
a
kind
of
pre-existing
set
of
points
which
would
basically
be
the
trust.
Basically,
an
fft
of
the
trusted
setup
pre-computer
fairly
easily,
and
you
just
take
the
first
object.
You
just
basically
do
a
fast
linear
combination
of
the
setup
to
get
to
a
block.
So
so
you
do
the
first
point:
multiplied
by
the
first
piece
of
data
plus
the
second
point:
multiplied
by
the
second
piece
of
data
and
so
forth.
So
kim
data
is
easy,
gener
verifying
a
proof
is
an
inclusion.
B
Proof
is
also
easy
and
basically
it's
just
a
single
pairing
check
and
now
generating
all
inclusion.
Proofs
is
the
thing
that
incred
has
been
working
a
lot
on
optimizing,
but
the
good
use
is
that
it's
still
something
like
41
or
250
lines
of
python
code
or
so,
and
so
you
can
probably
just
take
the
to
take
the
python
code
and
translate
it
so
my
opinion
is
that
it
really.
It
should
not
be
all
that
difficult
actually
and.
I
E
B
E
Okay,
so
in
terms
of
the
state
of
the
bls
libraries
that
we
can
use,
remember
that,
with
my
very
first
talk
with
supranational
back
in
april,
that
was
one
of
the
things
they
wanted
to
look
at
the
multiscalar
mule.
But
I
don't
think
it's
ready.
Yet.
However,
consensus
has
a
library
called
golf
and
gnark
for
snacks
and
12
381,
and
they
have
the
multiscalar
multiplication
that
is
also
multi-threaded
and
that
they
optimized
heavily
and
the
zxz
project
has
also
a
library
in
rust.
B
Oh
excellent,
so
I
know
looking
at
the
the
libraries
that
are
being
used
for
snarks
definitely
seems
like
a
potentially
fruitful
route
to
take,
but
they're
one
thing
I
wants
to
stress
is
that
there
definitely
is
value
from
working
on
the
cate
pieces
sooner.
The
reason,
basically,
is
that
we
really
wants
to
just
get
the
statistics
on
how
what
it,
what
is
the
run
time
of
one
of
these
things
in
practice,
I
mean
basically
adjust
them
like.
If
we
have
that
statistic,
I
think
it
significantly
de-risks
the
whole
thing.
A
B
J
I
mean
related
to
the
data
availability
sampling.
I
guess
one
aspect
is
the
then
possibly
you
know
slightly
modified
dhts
with
new
properties
like
low
latency,
and
I
guess
one
of
the
things
we're
looking
to
do
is
is
hire
a
networking
expert
who
could
maybe
help
us
a
different
foundation
investigate
these
issues.
A
A
A
A
B
Yep
makes
sense,
no,
I
mean
for
anyone
listening.
The
quick
update
is
basically
that
there's
some
multiple
small
tweaks
to
the
fork
choice
rule
that
we
have
been
mulling
over
in
order
to
address
all
of
the
issues
that
some
academic
people
have
found
with
the
fork
tourist
role.
Basically,
some
theoretical
issues
with
liveness,
so
yeah
we
will
like,
and
the
idea
the
the
ideas
on
exactly
what
to
do
have
been
around
for
a
couple
of
months
now,
but
just
kind
of
pushing
them
forward
to
something
close
to
a
ready-to-go
stage.
A
And
kind
of
underneath
that
is
more
of
a
general
just
contemplation
of
liveness
in
general,
because,
as
you
aware,
the
fork
choice,
you
know
is
lmd
ghost,
but
then
has
a
number
of
these
like
tweaks
and
fixes
to
make
it
more
alive.
Under
the
attacks
found,
which
is
a
game
of
whack-a-mole,
which
is
maybe
not
the
like.