►
From YouTube: Eth2.0 Call #41 [2020/6/10]
Description
A
A
A
A
A
B
It's
definitely
touring,
though,
so
we
weren't
too
many
bugs,
and
it
brings
up
this
whole
wall
of
debate,
and
I
wanted
to
talk
about
how
clients,
either
the
earlier
directed
towards
a
wallet
or
towards
a
key
store.
They
should
try
and
like
convert
to
this
design
and
light
us
as
some
strong
points
to
use
a
key
store,
specifically
instead
of
being
welded
centric,
then
I
made
some
changes
to
serenity
will
be
integrated
into
rumor.
I'm
planning
to
make
a
chain
test
to
process
many
blocks,
and
I
have
some
more
like
that's
not
like
testing.
B
It's
just
this
open
source
explorer
wrapping
thing
which
so
you
explain
the
latest
currently
as
an
api
that
exposes
some
functions,
information
and
blocks,
and
this
passion
tooling
can
interpret
this
process
it
into
a
database
for
you
to
analyze
the
whole
business
and
I've.
Given
our
users
access
to
this,
to
build
more
statistics
and
figure
out
where,
if
one
photo
thing
goes
wrong,
where
fork
secure
was
taken
from,
looks
like
all
these
kind
of
statistics.
C
We
also
found
the
panic
in
lighthouses
in
our
crate,
when
decoding
non-ufa
characters,
which
was
fixed
almost
immediately
by
age.
We've
been
working
on
integrating
load
star
as
well,
and
we've
identified
four
unique,
bugs
two
type
errors
in
the
enr
library
and
two
other
type
errors
in
the
block.
Ssd
generalization-
I
guess
in
other
news-
we've
also
been
helping
with
some
bls
fuzzing
on
the
e1
front,
with
the
guest
team
reported
a
few
issues
there.
C
But
I
guess
it's
not
really
in
the
scope
of
this
call,
since
no
one
here
is
using
that
school
library,
but
it
was
worth
mentioning
we're
working
towards
dockerizing,
e3,
fuzz
and
we'll
be
pushing
this
to
lockerhub
so
that
the
community
can
help
find
bugs-
and
I
guess,
speaking
of
dockers,
we've
analyzed
the
oss
fuzz
requirements
and
are
pretty
confident
we'll
be
able
to
have
our
fuzzers
running
on
the
google
infrastructure.
Very
soon.
That's
pretty
much.
It.
C
A
A
But
I
threw
up
an
item
here:
validator
key
hygiene,
there's
a
lot
here
and
maybe
we'll
end
up
having
to
take
some
discussion
out,
but
the
original
reason
I
put
it
up.
There
was
the
practices
that
we're
going
to
want
validators
to
take.
We
need
to
start
training
them
to
do
them
today
with
respect
to
our
test
nets,
rather
than
giving
them
higher
requirements
on
our
different
requirements.
A
Once
we
reach
maintenance,
for
example,
you
know
not
storing
your
withdrawal
credentials
or
even
maybe
generating
your
withdrawal
withdrawal
credentials
on
the
same
machine
that
you're
going
to
be
staking
on
thinking
about
air
gap
machines.
Thinking
about
some
of
the
trade-offs
here.
There
are
also
other
components
of
this
conversation,
including
well,
it's
first
key
stores
how
tied
all
your
keys
are
together
all
that
kind
of
stuff.
A
D
A
Yes,
absolutely
and
we're
actually
we're
talking
with
another
security
firm
to
do
a
top-down
look
at
validating
for
hobbyists,
which
would
be
include
some
key
recommendations,
but
also
include
things
like
dos
mitigation
and
managing
reports
well
and
all
that
kind
of
stuff.
So
there
is
some
some
work.
Certainly
some
work
to
be
done
here.
E
For
some
prism
here,
we've
we've
had
a
lot
of
we've
been
thinking
a
lot
about
this
and
we're
currently
working
on
a
whole
accounts
redesign
and
how
people
deal
with
their
keys.
I
think
we're
planning
on
maybe
like
name
spacing
kind
of
basic
commands
versus
advanced
power,
user
commands
and
yeah.
I
agree
like
like
we're
going
to
focus
a
lot
on
making
sure
users
know
what
to
do
with
their
withdrawal
withdrawal
credentials
where
to
put
them.
But
overall
most
of
the
feedback
comes
down
to.
E
Like
you
know,
kind
of
commands
are
not
intuitive
like.
How
can
I
move
my
accounts
from
one
computer
to
another?
You
know
where
are
my
keys
like
how
do
I?
How
do
I
safely
move
them
around?
So
that's.
We
feel
like
there's
a
lot
of
friction
there
and
that
would
be
super
helpful
if
we
can
all
like
kind
of
think
about
that
together.
B
B
That's
just
a
bare
json
file,
no
gimmicks,
no,
not
no
clutter,
no
index
files,
no
nothing!
It's
just
the
json
file
with
the
key,
which
makes
deployment
very
easy
if
you
can
just
produce
the
p
and
the
secrets
are
managed
separately
and
are
managed
well
in
the
sense
that
you
have
them
in
some
foul.
You
can
protect
this
file
from
various
kinds
of
problems,
and
you
are
very
explicit
about
including
federatives
or
not,
and
it
checks
if
new
5
datas
are
included
by
accident.
B
There's
a
lot
of
practices
here,
I'd
like
other
clients
to
look
into
for
their
security.
So
and
then
I
know
baku
is
following
suit
there.
It's
like
doing
similar
things,
except
that
the
it's
looking
like
it
will
be
more
flattened
structure
so
not
like
one.
There
are
three
verified
data,
but
more
like
a
few
files
per
validator
in
one
directory,
and
this
all
it's
more
of
the
same
that
my
point
here
is
what
account
or
what
t-star
type
you
use.
G
G
So
it
is
a
bit
hard
to
propose
this
and
I'm
a
little
more
concerned
about
there
being
multiple
versions
out
there.
So
if,
as
client
teams
you'll
see
this
and
it's
something
you'll
do
it,
then
I'd
like
to
go
ahead
with
it,
and
then
we
can
just
sort
of
ignore
the
earlier
version,
but
otherwise
I'd
prefer
not
just
have
a
sort
of
form
of
variance.
G
So
the
arguments
that
the
benefits
are
supposed
to
be
three
four
one
is
that
the
last
multiplying
complication
as
in
secret,
shared
keys
secret,
shared
key
scheme,
is
ever
going
to
be
able
to
follow
a
path
anyway.
So
it
doesn't
really
make
sense
for
me
to
talk
about
parts
if
you
can
be
using
secret
shared
keys,
because
by
definition
you
don't
know
where
they
exist.
G
And
then
things
like
staking
services
will
staking
services.
You
can
still
use
this
to
generate
your
keys.
So
say
you
want
to
have
your
withdrawal
keys
and
the
staking
service
is
going
to
separately,
derive
you
well,
then
your
withdrawal
keys
are
going
to
be
yours
anyway,
and
you
can
derive
the
card
to
not
have
or
not
use
the
signing
keys
for
hardware
wallets
and
so
that
the
the
one
approach
would
be
to
have
two
separate
mnemonics.
H
A
So
help
me
understand
in
the
in
the
argument
for
clients
not
knowing
or
caring
about
wallets
and
instead
just
caring
about
key
stores
that
provides
kind
of
maximum
flexibility
in
how
you
ultimately
manage
your
keys
right.
The
more
you
put
a
wallet
embedded
in
like
wallet
standards
have
to
be
embedded
in
a
client.
The
more
you've
become
one
opinionated
on
how
people
generate
the
keys
and
two
likely.
If
you
use
this
key
generation
where
withdrawal
credentials
and
and
signing
keys
are
generated
from
the
same
wallets.
A
A
I
G
Allows
a
lot
more
flexibility
and
I'd
argue
for
simplicity.
Furthermore,
I
really
don't
think
that
clients
should
necessarily
want
to
hold
on
to
withdrawal
keys
yeah.
No,
not
again,
that's
just
scary,
and
I
think
the
few
secrets
you
can
hold
on
towards
the
client
better,
but
I'm
open
to
part
arguments
on
that
point.
Okay,.
C
B
A
A
How
to
use
keys
and
key
stores
in
clients
is
there
anything
else
I
mean.
I
know
the
first
encapsulated
a
lot.
I
I
think
that
we
probably
need
to
take
there's
a
lot
here
to
discuss.
We
probably
need
to
continue
the
conversation
in
other
threads
and
potentially
get
on
a
call
and
hack
through
this.
I
think
we
have
a
lot
of
other
things
to
cover
today.
A
B
A
G
J
K
L
G
N
N
G
G
G
A
A
Cool
well,
there's
a
lot
there
and
it's
standards
are
important,
but
even
of
the
utmost
importance
is
getting
people
to
have
just
good
hygiene,
regardless
of
the
standards
and
not
allowing
them
to
make
really
bad
stupid
mistakes.
Okay,
thanks
I'm
trying
to
think
where
this
conversation
can
happen
organically
over
the
next
few
days.
Does
anybody
have
a.
A
O
O
We've
had
a
big
focus
on
our
memory
footprint
in
the
last
sprint,
and
we've
managed
to
reduce
the
remarkable
memory
use
for
hot
states
and
we've
just
merged
a
big,
rework
and
refactor
that
limits
a
number
of
states
stored
in
memory
and
regenerates
them
as
needed.
So
looking
for
some
good
improvements
there
other
than
that,
mostly
fixing
bugs
I'll
spare
you
the
the
details,
you
can
check
our
pr's
if
you're
interested,
reducing
the
noise
in
our
logs
and
improving
usability
generally,
I
think
that's
pretty
much.
It.
A
A
D
D
D
D
On
the
visualization
side,
we
updated
the
graph
and
monitoring
so
that
it's
a
bit
clearer
to
monitor
a
single
node
before
you
monitor
the
the
wall
fleet
on
the
test
nets
witty.
So
we
had
some
exciting
news
for
mobile
users.
Now
you
can
start
nimbus,
have
your
computer,
your
phone
sleep
for
a
night
and
on
wake
up
it
will
re-sync
without
any
issue.
Well,
at
least
it
did
at
least
once.
D
D
We
have
a
few
platform
specific
bugs
or
regression
so
bug
one
is
on
windows
32-bit.
I
really
hope
no
one
is
using
that,
but
we
are
still
testing
windows
32-bit,
because
it's
the
best
way
in
ci
to
test
32-bit
platforms,
and
we
have
a
regression
on
arm
64
that
we
are
investigating
and
overwatch.
We
had
a
lot
of
bug
fixes
our
async
framework,
lib
p2p,
in
particular,
memory
usage
and
links,
and
that's
all.
A
A
M
C
C
Paul's
been
busy
rewriting
of
choice
too
much
0.12.1
and
it's
now
fully
separated
into
its
own
crate,
which
is
good
and
makes
it
much
easier
to
hold.
It
he's
actually
raised
two
interesting
issues
with
the
spec.
The
first
one
removes
a
redundant
database
lookup
and
the
second
one
addresses
an
issue
that
can
potentially
lead
to
a
corruption
of
the
fork
choice
store.
It
actually
also
removes
a
redundant
function.
Call
in
other
news.
C
We've
made
our
memory
usage
available
to
each
to
stats,
so
not
all
lighthouse
nodes
on
which
key
have
that
updated
enabled,
but
for
those
who
have
it
on,
you
can
see
that
the
optimization
efforts
over
the
past
few
months
definitely
paying
off.
We
are
now
natively
supporting
raspberry
pi's
big.
Thank
you
to
an
external
contributor
who
managed
to
get
level
dp
to
build
on
arm.
C
We
were
waiting
on
that
pr
to
be
merged
upstream
for
a
while,
and
it's
been
done
recently,
so
we've
updated
our
docks
to
make
it
super
easy
for
people
to
build
on
raspberry,
pi
age
has
finished.
Rebuilding
this
v5.
Some
people
were
noticing
massive
cpu
usage
on
schlesi
and
it's
now
completely
resolved.
C
We
also
have
greater
concurrency,
pretty
solid
boss
resistance
structure
and
we
no
longer
require
enrs
for
peer
connection.
We
can
just
use
multi-others
and
I
guess
finally,
trail
of
bits
have
completed
their
first
round
of
the
external
security
review
they're.
Just
waiting
on
few
of
our
comments.
Before
releasing
the
report,
I
guess
we're
happy
to
say
that
they
haven't
found
anything
critical
at
this
stage.
K
A
P
Hey
guys,
so
we
are
lined
to
spec
version
12.1.
We
have
shot
done
the
topaz
test
net.
We
launched
the
onus
test
now
with
version
12.1,
we're
still
4
000
deposits
away
from
the
genesis
cons.
So
from
the
looks
of
it
I
think
genesis
will
be
sometimes
saturday
afternoon,
pacific
time
we
also
doing
some
sanity
testing
on
multi-client
compatibility
with
them
own
it.
So
so
far
we
have
tried
taku,
we
verified
that
it
sees
that
either
one
deposited
the
same
way
prism
does
so
that's
good
news.
P
We
will
try
lighthouse
next
and
then
and
if
anyone's
clients
ready
for
0
12
feel
free
to
ping,
us
we'll
be
happy
to
launch
it
and
insanity
test
it.
We
now
have
offer
of
peer
go
support,
so
you
can
run,
go,
get
and
start
developing
in
your
favorite
test
editor
and
then
run
your
tests
and
stuff,
and
lots
of
people
are
happy
with
this.
P
P
P
In
the
background,
we're
also
working
on
revamping
the
validator
key
management,
so,
like
people
said
we're
researching
the
we're
researching
the
eips,
we're
studying
how
other
clients
do
it.
In
the
current
tooling
landscape,
we
have
been
getting
lots
of
feedback
from
users
on
that
component,
so
the
new
ux
is
very
important
there,
other
than
that.
I
just
bunch
of
minor
bug,
fixes
total
health
improvements
and
then
optimizations
and
yeah.
That's
about
it
great.
Q
Sorry,
sorry,
I
wasn't
mute
so
the
the
thing
that
I'm
working
now
on
is
the
ethereum
2e2m1
integration
in
nethermine,
so
both
of
them
working
on
undermined
and
accepting
deposits
and
the
whole
flow
going
through
and
then
I'll
be
updating
also
to
the
latest
spec.
So
this
auto
form,
I
believe-
and
we
start
looking
at
some
of
the
updates
to
the
api
yeah.
So
these
are
the
main
projects
at
the
moment
and
the
testing
full
testing.
They
want
to
read
all
the
tests
to
run
them
automatically.
D
A
R
Hey
everyone,
let's
see
so
the
main
work
over
the
last
two
weeks
on
trinity,
has
been
spec
updates
to
get
up
to
11.3
grant's
been
working
on
that
some
work
on
looking
at
optimizations,
so
that
we
can
comfortably
run
the
mainnet
configuration
and
working
on
implementing
an
efficient
fork
choice
we're
looking
at
using
the
proto-array
implementation.
That
seems
to
be
pretty
popular
and
that's
about
it.
A
A
A
No
major
issues
have
been
found,
altona,
which
is
the
v012
next
test
set
to
be
launched,
expected
to
happen
in
the
next
week
and
a
half,
but
right
now,
there's
still
only
one
client,
that's
like
fully
either
12,
that's
prison,
so,
looking
at,
ideally,
we
could
launch
the
four
clients
this
time.
Nimbus
will
be
able
to
hope,
avery's,
confident
that
nemesis
will
write
a
genesis
validator
as
well.
A
That
said,
moving
forward
we'll
invite
the
client
teams
for
genesis,
so
they
have
a
chance
to
run
their
unknowns
at
launch
a
little
bit
larger
nets,
a
little
more
chaos
and
I'm
adding
vanilla
flavor
to
this
and
if
alternate
works
out,
then
we
can
prepare,
for,
I
won't
say
the
word,
but
a
larger
scale
public.
It's
a
client
testimony,
okay,
cool
thanks,
alfred
and
moving
on
to
the
api
working
group.
Update
marin
is
really
had
us
been
leaving
this
a
lot.
A
He
wasn't
able
to
join
us
in
the
call.
His
quick
update
is
merge.
The
slash
node,
namespace,
endpoints,
there's
openpr's
and
the
slash
beacon,
slash,
state
and
slash
beacon,
slash
pool
endpoints
in
progress
is
slash,
beacon,
blocks
and
missing
is
the
slash
config
and
the
slash
validator
endpoints.
If
you
are
interested
in
this
stuff,
there
are
two
open
cars
for
review.
They've
gotten
a
little
bit
of
review.
A
So
far,
I'm
going
to
take
a
look
at
them
today
and
like
immerse
them
very
soon
and
again
keep
your
eye
out
for,
as
you
review
things
that
are
difficult
to
implement
and
things
that
you
know,
people
need
to
be
able
to
do
and
it's
difficult
for
it
would
be
difficult
for
them
to
do.
That
would
be
a
signal
that
something
is
not
so
elegant
or
something
is
missing
in
this
api.
A
In
terms
of
timeliness
completeness,
I
think
that
we
generally
have
the
roadmap
for
kind
of
the
space
b1
and
that
most
of
it
likely
by
the
end
of
next
week,
will
be
in
this
rebo.
And
at
that
point
we
can
kind
of
go
back
and
forth.
If
there's
any
continued
issues,
but
we
can
do
you
know
we
can
do
a
release
and
call
everyone.
A
M
Yeah
so
myself,
dink
rat
some
with
the
help
of
some
academics
and
justin,
and
other
people
have
been
looking
at
virgo
trees,
which
are
and
other
like,
basically
alternatives
to
merkel,
trees
for
estate
storage
that
how-
and
so
I
wrote,
an
eighth
research
post
that
basically
kind
of
specifies
what
the
problem
is
about
a
couple
of
weeks
ago.
The
problem
is
basically
that
you
want
something
that
has
all
the
properties
of
a
merkle
tree.
So
it
can
it's
a
commitment.
M
So
there,
the
main
kind
of
alternative
to
this
so
far
has
been
the
cave
commitment
which
lets
you
have
a
48
byte
proof
for
basically
an
unlimited
number
of
elements,
except
it
has
this
a
kind
of
fatal
flaw
that
if
the
data
changes
even
slightly,
then
you
have
to
do
a
huge
recomputation
over
the
data
in
order
to
be
able
to
continue
making
proofs.
And
so
we've
been
trying
to
figure
out
how
to
kind
of
move
past
that
and
the
more
recent
kind
of
direction
that
at
least
I've
been
going.
M
And
I
mean
the
ingredient
was
there
even
ahead
of
me
as
virgo
trees,
which
is
basically
a
kind
of
merkel
tree
style
construction
made
out
of
cake
commitments,
so
basically
a
tree
where
the
width
might
be
something
like
you
know,
somewhere
in
between
256
and
16
000.
They
haven't
decided
yet,
and
you
would
have
a
tree
of
these,
and
so
you,
you
would
make
a
proof
by
basically
just
having
like
the
same
way.
M
You
would
make
any
other
proof,
except
because
the
tree
has
a
much
larger
width
and
because
that
gauge
groups
are
single
objects,
so
the
proof
size
would
be
like.
Basically,
something
like
96
bytes
per
element
is
isn't
looking
likely.
So
I
mean
still
evaluating
this,
but
it's
also
a
potential
like
candidate
to
replace
things,
even
merkel
tree
binary.
A
M
H
H
A
K
The
spec
supports
it,
but
yeah
the
implementation.
So
it's
an
implementation
specific.
I
guess
we
had.
We
had.
We
had
some
issues
with
our
cpu
usage
now,
so
we
pretty
much
just
kind
of
re
refactored
everything
we
kind
of
rebuilt
it
from
the
ground
up,
so
it
can
support
it.
I
think
you
can
only
support
inline
peer
key,
like
peer
id,
so
like
sep,
256,
k1
and
ed25519
keys,
but
we're
using
those
anyway.
So
so
you
can
do
it
yeah.