►
From YouTube: Eth2.0 Call #32 [2020/1/23]
Description
A
A
Sharing
right
there
first
on
the
agenda,
testing
release
updates.
As
you
know,
if
you've
been
trying
to
work
on
e010,
we
had
some
issues
with
the
bls
test
generators.
We
didn't
update
them
to
the
new
apis
and
there
was
a
failed
soc
generic
tests,
which
messed
up
those
generators
due
to
some
like
import
issue.
A
A
A
Proto
is
not
here,
but
proto's
been
doing
a
bunch
of
work,
getting
the
repo
updated
to
3.8,
also
integrating
his
remarkable,
which
greatly
greatly
speeds
up
the
pi
spec
to
something
like
I'll.
Let
I'll
let
him
share
the
numbers
if
he
joins
us,
but
very
very
fast
to
the
extent
that
we
can
start
doing
a
little
bit
more
interesting
tests
and
things
with
pi
spec.
A
So
that's
great
in
addition
to
that,
I've
been
working
on
integrating
those
structurings
into
what's
going
on
with
the
phase
one
stuff
and
phase
one
at
least
as
it
stands
today
will
be
finally
gotten
out
of
that
pr
into
dev
still
a
lot
of
work
to
do,
but
the
build
passes.
There's
some
some
base
sanity
tests,
things
like
that
cool.
None
of
that
will
affect
most
of
you
too
much,
except
for
that
release.
B
Yeah
sure
I've
got
a
beacon,
fuzz
update,
excellent,
hey
everyone.
Since
our
last
update
on
this
goal,
we've
published
comprehensive
blog
posts
detailing
our
approach
and
current
challenges
with
beacon,
fuzz
we've
confirmed
that
the
crash
identified
on
nimbus
is
indeed
a
bug
related
to
the
committee
function
as
part
of
the
eiffel
station
processing.
B
So
essentially,
when
passed
invalid
or
out
of
bounds
community
index,
the
compute
committee
function
raises
an
assertion
error,
which
leads
to
a
crash
and
we've
just
identified
yesterday,
an
issue
in
trinity
related
to
the
validate
proposal
slashing
function
and
it's
actually
also
affecting
the
validate
voluntary
exit
function.
So
basically,
these
two
functions
crash
went
past
an
operation
with
an
invalid
validator
index
so
essentially
index
errors.
Exceptions
are
not
handled
as
validation
errors,
we've
opened
an
issue
and
submitted
the
pr
for
a
fix,
and
it
was
actually
approved
a
couple
of
hours
ago.
B
So
it's
always
exciting
to
see
beacon,
fuzz,
finding
more
issues
out
there,
we've
revamped
the
way
we're
building
fuzzers.
We
made
the
build
process,
a
lot
more
maintainable.
Basically,
less
coffee,
basting
we've
deployed
a
few
more
fuzzers
on
fuzzy,
we're
still
exploring
ways
to
fix
the
namespace
clash.
We
have
been
dealing
with
basically
two
goal-line
implementations,
so
the
blog
post
explains
in
detail
all
the
possible
options
and
prashan
mech
is
currently
essentially
trying
them
all.
We
should
hopefully
have
this
resolved
by
next
monday.
B
So
we've
therefore
submitted
a
pr
to
introduce
a
compile
time
flag
to
skip
the
ls
signature.
Verification
in
nimbus
we'll
have
a
new
blog
post
detailing
our
progress,
either
at
the
end
of
next
week
or
beginning
of
the
following
week,
and
as
soon
as
a
couple
of
clients
are
upgraded
to
the
latest
version
of
the
spec,
we'll
be
updating
our
fuzzers
accordingly,
that's
it
for
beacon.
First,
thank
you.
B
A
B
D
A
E
F
G
B
B
I
think
our
general
recommendation
would
be
to
propagate
these
errors
the
right
way-
and
you
know,
checking
for
these
assertions
and
not
basically
crashing
when
they
happen,
so
allowing
your
your
client
to
recover
from
that
which
should
not
be
too
complicated.
So
we
almost
have
a
pr
to
fix
that
particular
bug
on
on
nimbus.
The
trinity
bug
is
again,
as
I
said
already
already
fixed.
Just
the
pian
just
needs
to
be
managed,
but
but
yeah
you're
right.
B
E
E
And
then
there
are
places
in
the
spec
where
empty
committees
are
not
checked
for
yeah.
So
I
think
the
case
like
that's
that's
kind
of
realistic-ish
like
if
you
have
really
bad
luck
with.
No,
I
shouldn't
get.
I
have
not
much
bad
luck
with
the
something,
but
if,
but
if,
if
you
have
very
few
validators,
some
of
the
committees
might
be
empty
and
some
might
go
on
so
technically,
there's
a
chance
that
this
chain
could
recover,
but
it's
not
very
meaningful
because
there
are
social
validators
and
we've
had.
E
We've
had
to
do
like
fixed
cases
like
that
and
those
those
were
handling
as
part
of
normal
processing,
even
though
it
doesn't
really
make
sense
and
neither,
from
an
economic
point
of
view,
to
have
a
change
with
so
few
red
letters
or
you
know,
to
keep
going
in
a
meaningful
way.
If
you
don't
have
any
validators,
then
you
can't
introduce
any
new
ones,
so
you
can
screw
it
anyway.
B
Yeah,
but
I
hear
you
make
sense,
I
think
I
would
say
generally
if,
if
we
can
make
sure
that
the
the
clients
can
recover
from
these
cases,
I
would
strongly
recommend
implementing
those
fixes
again
for
for
nimbus.
For
that
particular
test
case.
I
think
the
fix
is
relatively
simple
and
definitely
for
trinity
that
that's
actually
the
invalid
index
is,
is
caused
by
a
a
mouthful,
basically
a
block.
It's
not
it's,
not
a
problem
with
the
state
itself.
It's
a
block,
processing
issue,
so.
B
E
G
B
H
Right
that'll
be
me,
so
we
merged
0.9.4
into
master
earlier
this
week.
We're
also
we've
made
all
the
changes
for
0.10.0
as
well,
including
all
the
bls
changes.
We
would
pass
the
reference
test
if
the
tests
were
correct.
We
won't
be
merging
this
just
yet
we're
going
to
wait
until
there
are
some
joints.
H
H
J
I
I
I
Yeah
yeah
exactly
a
thousand
x
and
then
so
when
you,
when
you
have
like
such
a
fast
hash
tree
root
like
hashtag
root,
I
don't
know
we
can
do
like
4
000,
hash,
hashtag
roots
of
a
merkle
tree
of
a
beacon
state
per
second.
So
when
you,
when
you
have
such
a
fast
hatchery,
you
can
use
that
as
like
a
as
like
the
the
key
of
a
of
like
some
kind
of
cache.
So
you
can
do
like
what
do
you
call
it?
I
I
I
guess
is
what
you
call
it,
so
you
can
memoize
these
different
functions
and
like
just
that,
speed
is
like
enough
to
speed
up
the
state
transition
by
like
a
lot
basically
for
for
us,
it's
like
we're
right
now
we're
just
not
fast
enough
for
mainnet
to
being,
like,
I
would
say,
pretty
competitive
for
mainnet,
so
we're
working
on
just
actually
benchmarking
out
getting
real
numbers
for
that.
So
we
I
can
say
instead
of
saying
a
lot,
I
can
tell
you
exactly
how
how
much
faster,
what
exactly
that
looks
like.
E
K
I'm
mute
okay,
never
mind.
Where
are
we
at
with
my
notes?
So
we've
been
working
on
peer-to-peer
using
the
rust
library
for
a
quick,
a
quick
solution
for
that
with
some
help
from
johnny.
Ria
we've
got
a
dot
net
example
working
on
os
x,
so
having
issues
on
linux,
but
we
just
got
to
implement
it
for
windows
and
then
integrate
in
with
our
main
application,
but
because
it's
the
same
library,
obviously
once
that
integrated,
it
should
just
talk
to
the
other
of
our
implementations.
K
L
We
have
another
pr
for
the
validator
client
to
pull
that
out
and
then
some
work
on
our
beacon,
node
apis
to
support
that,
and
probably
our
most
exciting
thing.
This
week,
ionic
has
been
working
on
our
disk
v5
implementation,
so
he's
doing
some
experiments
connecting
to
lighthouse
we
can
successfully
put
on
enrs
from
their
network.
So
that's
pretty
cool
and
yeah.
That's
those
are
the
main
things
working
towards
public
test
nuts.
A
M
Yeah,
hey
everyone
from
christmas,
so
we've
been
running
our
mainnet
test
net
for
two
weeks
with
not
not
really
significant
issues.
So
we
have
32
000
active
out,
29
thousand
active
out.
There
is
32
000
total
and
at
the
moment
we've
been
just
working
through
rapid
iteration
with
users
on
a
lot
of
improvements
to
kind
of
the
user
experience.
G
M
M
You
know
one
validator
request
or
some
piece
of
data
there's
a
worker
in
the
background
that
kind
of
delegates
and
and
returns
that
value
to
any
other,
any
other
future
validators.
That
might
request
it.
Aside
from
that,
the
other
biggest
bottleneck
was
four
choice,
but
terence
worked
with
proto
and
paul
to
get
that
implementation
and
and
fixed
it
into
prism.
So
now
we're
basically
seeing
it
disappear
from
our
frame.
M
Aside
from
that,
we
have
this
slasher
architecture
that
is
listening
to
at
the
stations
and
things
happening
on
the
test
net
and
essentially
we'll
you
know
we'll
track
slashing
offenses
and
submit
that
to
the
beacon
node.
So
we're
still
working
on
wrapping
up
that
that
aspect
of
slash
of
of
this
last
year
itself
yeah.
So
I
would
say
the
biggest
issue
right
now
is
just
fixing
up
resource
consumption
of
the
beaker
of
the
beacon
nodes
at
the
moment.
M
M
On
the
network
yeah
so
on
average
notes
have
around
80
to
100
peers,
there's
a
new
one.
There's
a
website
that
came
out
recently
called
to
e3
stats,
dot
io
created
by
alethio.
So
essentially
they
show
people
can
register
their
nodes.
So
you
know
we
only
run
on
the
order
of
like
seven
or
so
we
know
the
community
runs
a
lot
more
than
that
so
yeah,
so
you
can
see
kind
of
which
ones
people
have
registered
on
there.
But
you
know,
aside
from
that,
we
haven't
done
a
recent
topology
mapping.
B
Yeah
that'll,
be
me
again,
so
we've
been
adapting
for
lambda's
proto-array
fork:
choice
to
work
in
an
e2
context,
we're
in
the
final
stages
of
testing,
and
it's
been
running
on
several
test
net
nodes,
we're
seeing
some
great
improvements
there.
By
the
way
we
still
need
to
investigate
one
era
we've
been
seeing
polls
on
it
and
yeah
paul's
a
big
fan
of
the
right
approach,
and
he
definitely
recommends
it
to
the
other
teams.
B
He's
gained
an
appreciation
for
the
nuances
in
the
choice,
role
and
we're
super
keen
to
see
some
cross-client
testing
and
hopefully
very
near
future,
we're
in
the
process
of
updating
to
0.10.0
our
bls
implementation
has
been
updated
in
the
last
couple
of
days.
We're
now
working
to
pass
test
vectors,
and
I
guess
a
rough
eta
for
a
first
working
version
would
be
late
next
week,
we're
adding
the
http
api
to
our
validator
client
to
allow
for
the
management
validators,
creating
validators,
deleting
validators,
exiting,
etc.
B
So
we've
been
addressing
all
reported
bugs
from
the
previous
zest
net
and
patching
lighthouse
as
new
ones
discovered.
We
built
a
new
dedicated
thread
for
block
processing
that
takes
the
load
out
of
other
lighthouse
processes,
which
was
causing
some
unexpected
issues
with
timeouts
we've
added
some
more
robust
thinking,
logic
to
handle
malicious
invalid
peers.
B
We're
now
testing
our
thinking
with
some
custom
adversarial
appears
on
the
testnet.
It's
going
going
pretty
smoothly
so
far,
we're
continuing
to
make
progress
on
what
we
call
our
v
0.2,
which
will
introduce
a
significant
network
upgrade
with
the
introduction
of
subnets
we're
seeing
a
lot
more
community
engagement
in
lighthouse,
which
is
great,
we've
been
taking
lots
of
feedback
and
implementing
lots
of
small
ux
fixes
we're
also
seeing
significant
interest
in
our
validator
client
ui
proposals.
B
You
guys
might
have
seen
the
rfp
that
we
pushed
out
a
few
weeks
ago,
we're
still
processing
the
responses.
The
deadline
to
respond
is
the
end
of
next
week,
31st
of
january,
to
be
precise
and
we'll
be
announcing
the
winning
vendor
shortly
after
we're
also
making
great
progress
on
the
hiring
front.
So
we're
looking
at
hiring
one
to
two
more
russ
developers.
B
Late
applications
are
still
accepted,
but
time's
definitely
running
out
we're
looking
at
moving
fairly
quickly
on
this
and,
finally,
we're
also
still
looking
for
people
to
help
on
a
contracting
basis,
with
some
devops
work,
primary,
primarily
sorry
around
deploying
and
maintaining
test
nets,
so
we're
looking
to
deploy
test
nets
with
hundreds
of
nodes,
especially
thousands
most
probably
using
aws.
So
please
reach
out
to
paul
via
discord
or
twitter
if
you're
interested
or
if
you
know
someone
who's
interested,
that's
it
for
lighthouse.
B
I
think
we
definitely
had
a
lot
of
a
lot
of
issues
when
dealing
with
folk
choice,
so
the
the
work
that
paul's
been
doing
lately
over
the
last
couple
of
weeks,
I'd
say
with
proto,
has
been
quite
instrumental
to
fixing
those
bugs.
But
apart
from
that
test,
that's
been
running
fine.
We
took
some
validators
offline,
which
resulted
in
some
skip
slots,
which
highlighted
some
bugs
that
we
haven't
actually
seen
before
in
our
sinking,
so
that
was
that
was
quite
interesting,
but
yeah.
B
B
A
Right
yeah,
I
see
the
20s
per
node,
I
guess
implies
somewhere
in
that
range,
if
not
more,
okay,
cool
thanks.
I
ask
I
just
you
know
I
think,
we're
all
keen
to
see
test
nets
with
more
validators,
but
at
this
point,
even
more
keen
to
see
test
tests
with
more
nodes.
I
think
you
know
the
20
to
100
range
is
still
slightly
in
the
the
toy
range
of
the
amount
of
nodes
we
expect
to
see
on
mainnet.
B
A
G
G
So
this
is
work
in
progress
and
we
are
looking
into
how
to
reuse
nimbus
ephraim
1
code
for
ethereum
2
phase
2.
with
regard
to
test
net.
We
are
in
now
we
can
use
a
mixed,
ep2p
or
goalie
p2p
demon
with
nimbus
and
I'll
hand
over
to
zari
after
the
other
updates,
so
that
he
can
explain
the
huddles
and
the
number
of
nodes.
What
your
questions
danny.
G
Otherwise
most
of
the
team
will
be
in
brussels
for
first
day
and
the
week
after
between
february
1st
on
february,
the
7th.
So
if
you
want
to
chat
or
meet
us
physically
you're
welcome
to
reach
out
to
us
on
our
discord
and
we
will
be
holding
a
kind
of
interrupt-like
event
and
we
will
in
particular
clone
other
clients,
test
nets
and
repo,
so
prison
and
lighthouse
so
that
we
can
test
with
everyone
physically
there.
That's
how
to
connect
to
those
clients.
G
We
also
had
some
weekend
projects
from
one
community
member
and
he
managed
to
build
a
nimbus
on
android
and
run
it
on
the
phone
and
otherwise
jasec
also
had
some
kind
of
weekend
project,
and
we
now
have
something
called
n
bind
gene
that
can
generate
bindings
to
rest
libraries.
So
you
can
easily
use
rust
libraries
within
nim
and
now
I'll
hand
over
to
zari
to
explain
what
we
have
on
the
test.
Dates.
N
Various
issues
that
arise
in
longer
running
test
nets,
for
example,
where
nodes
are
restarted
or
joined
the
network
later
or
we've
seen
various
issues
with
the
data
structures,
the
database
maintained
by
the
node
and
the
algorithms
that
initialize
the
data
structures
for
what
we
call
vlog
pool
and
attestation
pool.
Basically,
we
are
seeing
that
sometimes,
when
the
nodes
are
restarted,
their
data
structures
are
not
initialized
properly
and
the
node
starts
misbehaving.
A
O
A
F
F
F
A
Thanks
so
much
yeah
I
mean
I
mentioned
before
ongoing
work
on
the
phase
one
specs
really
hoping
to
see
something
relatively
clean
and
stable
in
the
next
couple
of
weeks.
I
want
to
give
a
couple
teams
something
to
dig
into
on
that,
so
we
can
start
seeing
some
prototypes,
but
we're
not
quite
there
yet.
A
P
Hey
how's
it
going
okay.
So
over
the
past
few
weeks
we've
been
working
on
a
couple
different
projects,
so
mikhail
has
been
working
on
this
e2
bridge,
and
I
have
some
notes
from
him
about
what
he
thinks
about
that.
If
anyone's
interested
and
kind
of
like
reviewing
the
proposals
and
documentation,
that's
out
there
right
now,
alex
has
been
working
on
some
decentralized
time.
Sync,
I
have
been
working
on
crosstalk
transactions,
just
mainly
like
reviewing
literature
and
working
on
this
python.
P
Q
We
basically
kind
of
specked
out
a
plan,
for
I
don't
know
like
a
truffle
or
or
an
ee
kind
of
test
framework
and
he's
kind
of
working
on
an
initial
implementation
of
like
a
transaction
ee-
and
I
am-
I
created
the
kind
of
like
a
a
cargo
plug-in
to
for
us
to
kind
of
generate
the
framework
of
an
e
but
I'll.
Let
I'll
let
I'll.
Let
matt
talk
more
about
this,
so
cool.
R
It's
sam
from
quilt
here,
some
stuff
we've
been
working
on
since
the
last
call.
We
hosted
a
phase
two
call
and
discuss
the
phase,
one
to
phase
two
transition
plan
and
a
general
phase
zero
to
phase
one
transition
plan,
there's
also
a
write-up.
We
released
to
support
that
anscar
and
I
released
the
state
provider
write-up.
R
R
R
Oh
I've
been
working
on
a
small
write-up
that
makes
the
case
for
investigating
dynamics,
get
access
I'll,
be
posting
that
soon
so,
hopefully,
you'll
all
be
interested
in
reading
that
we've
been
going
through
scenarios
on
our
crush
rod,
framework
for
managing
ethan
ee
balances,
and
I
think
that's
pretty
much
everything
we've
been
working
on
as
well.
Let
me
know
if
I
missed
anything
guys.
A
Thank
you
networking,
so
we
do
have
a
call
in
about
six
days.
A
networking
call,
I
think,
the
core
of
which
we
will
address
any
practical
items
related
to
the
sync
current
specs
issues,
we're
seeing
and
then
move
on
to
more
researchy
items
if
they,
if
we
have
time,
there's
also
this
pr
up
for
adding
a
response
code,
it
looks
like
there's
a
lot
of
active
discussion.
I
didn't
have
time
to
review
it
this
morning,
but
if
it's
still
up
for
debate
on
wednesday,
we'll
hash
it
out,
there.
E
E
O
Items
yes,
so,
although
I've
been
busy
with
lots
of
other
things,
there
are
the
naive
attestation.
Aggregation
technique
is
getting
improved,
so
I
want
to
do
some
careful
improvements
so
like
not
directly
pivot.
To
like
this
one
new
aggregations
aggregation
strategy
that
completely
changes
things
instead,
I
think
we
can
at
least
get
a
lower
upper
bound
on
the
like
on
the
cost
of
local
aggregation,
while
still
being
ghost
absorbed
compatible,
and
so
this
basically
means
we
can
I'm
talking
about
collapse.
O
People
to
achieve
this,
we
can
change
how
we
track
what
other
players
know
and
what
you
decide
to
drop
and
doing
this
you
can
decide
to
drop
messages.
That's
already
part
of
aggregates
that
are
known
by
your
peers,
and
so
you
can
try
and
reduce
messages
that
way,
while
still
being
like
able
to
propagate
these
aggregates.
O
A
A
A
Discuss
herman
shared
1578,
which
was
an
issue
posted
by
justin
for
dual
key
voluntary
exits,
which
allowed
either
the
hotkey
or
the
colt
key
for
the
voluntary
exit.
I
think
the
main
pushback
on
that
is
that
the
cold
key
in
the
long
run
probably
won't
be
a
key,
but
instead
a
piece
of
code
or
a
pointer
to
an
e
and
a
message
rather
than
a
key.
I
suppose.
A
A
And
I
guess
specifically
it's
worth
highlighting
the
use
case
here,
the
use
case
likely
being
I
I'm
in
a
custodial
staking
service.
I
have
the
cold
key.
I
do
not
have
the
signing
key
and
the
staker
starts
doing
something
wrong.
If
they
do
something
slashable
they'll
be
kicked
out,
but
maybe,
for
instance,
they
go
offline,
they
go
totally
dark.
I
can't
I
can't
talk
to
them
rather
than.
A
J
A
A
Strange
cases
in
which
someone
maybe
an
adversary,
who
makes
a
some
fork
of
the
chain,
could
take
some
of
these
messages
and
make
you
exit
early
in
this
fork,
and
so
there
are
subtle
risks
there
that
are
not
that
detrimental
likely
in
most
cases.
I
need
to
think
about
a
little
bit
more,
but
that's
probably
a
reasonable
approach.
I
forgot
that
was
suggested
there.
G
Not
really
spec
discussion
but
as
a
general
comment,
I've
implemented
the
hash
two
curve.
Spec,
the
new
one
for
0.10
and
cryptospec
is
quite
nice,
because
it's
it's
blending
high-level
goals,
goals,
the
design,
rationales
and
the
implementation.
So
you
have
both
the
implementation,
which
is
what
we
have
and
also
why
we
are
doing
things
like
this,
and
I
know
that
we
had
some
feedback
about
the
spec
being
kind
of
obscure
about
on
the
intent
and
well
that's
just
a
comment.
H
It
may
be
a
good
time
to
unveil
my
secret
weekend
project,
which
is
to
put
together
an
annotated
spec.
So
I'm
working
on
that
with
rationale
and
digging
through
github
for
all
the
reasons
why
we
did
all
that
stuff,
because
this
has
been
a
pain
point
for
a
long
time.
So
that
is
something
I'm
just
doing
as
a
personal
project,
but
there
may
be
other
efforts
underway,
yeah.
A
A
E
A
Yeah,
absolutely,
I
will
not
be
in
paris,
but
some
people
from
my
team
certainly
will
be,
and
I
know
others
will
so
organize
the
way
I
I'm
excited
to
hear
about
y'all's
individual
interop
effort
to
mess
with
some
multi-client
test
sets.
Maybe
when
others
get
together
at
some
of
these
events,
that
might
be
a
good
target
as
well.
B
B
A
A
I'll
have
to
look
at
that
real,
quick,
I'm
gonna
be
on
a
plane
that
day
at
the
exact
time
of
this
call,
so
we'll
schedule
around
that
or
someone
else
will
run
the
call
I'll.
Let
y'all
know
soon
thanks.
Everyone
appreciate
the
good
work
talk
to
a
lot
of
y'all
at
the
networking
call
you
know,
keep
pushing
on
those
test
sets
thanks.
Everyone.