►
From YouTube: Eth2.0 Call #61 [2021/4/8]
Description
A
We
will
discuss
altair
a
bit
peritosh
and
I
think
leo
are
going
to
talk
about
some
metrics
naming
that
might
be
useful
talk
about
research
updates.
If
you
you're,
probably
aware
there's
a
number
of
other
things
going
on.
Specifically
the
ryanism
calls
there's
a
golf
call
yesterday.
Thank
you
proto,
and
there
was
there's
also
a
fortnightly.
A
Merge
specific
call.
So,
although
we
can
certainly
answer
a
couple
questions
here,
if
you
want
to
dig
in
any
of
that,
I
think
it'd
be
best
to
use
the
appropriate
channels
and
the
appropriate
calls
to
dig
deep
into
that.
I
think
the
focus
here
will
likely
be
on
on
alt's
hair.
For
the
time
being,
I
on
the
client
updates
I'd
love
to
hear
just
general
progress
on
altair,
specifically
just
kind
of
the
feel
on
where
we're
at
on
engineering.
A
B
B
B
So
that's
us
for
our
tier
we're
pretty
confident
that
once
we
have
the
foundation
for
the
hard
working
logic
done,
then
the
rest
can
move
pretty
quickly
and
in
terms
of
the
merge
we
release
a
demo
for
prism
and
catalyst.
So
I
hope
that
people
have
tried
that
and
on
the
current
work
front
we
did
some
optimization
for
the
slasher
db
schema
for
a
more
efficient
storage.
B
A
Thank
you.
I
have
a
question.
I
request
when
y'all
do
figure
out
the
ssd
decoding
issue,
if
that
is
in
fact,
some
sort
of
corner
case
that
we're
not
covering
in
the
sd
test.
Let
us
know
so
we
can
get
a
test
specific
for
that
in
the
in
the
right
place,
rather
than
kind
of
implicit
in
the
poor
choices.
D
Hey
everybody
so
real
quick.
Let's
we
cut
a
new
release
0.19
on
on
tuesday,
it's
pretty
chunky
and
we're
now
supporting
the
latest
lts
of
node
version
14..
We
added
queuing
to
our
gossip
validation
engine
and
we
also
have
threaded
bls
verification
now.
So
all
these
things
kind
of
combined
much
more
stable,
node
running
as
far
as
altera
goes.
We
have
done
a
lot
a
lot
of
the
preliminary
work
for
for
altair,
just
ensuring
that
we
have
support
for
different
data
structures,
updating
the
database.
A
F
A
F
No,
so
we
haven't
done
the
four
choice
ones,
just
the
consensus,
one
so
far,
it's
all
by
that.
I'm
passing
those
we're
also
working
on
alternate
networking
with
twine
and
age.
We
have
our
doppelganger
implementation
in
for
review.
That's
the
protection
against
running
multiple
dc's.
We've
been
doing
a
lot
with
the
memory
allocated.
Still
we've
got
kind
of
three
to
six
times:
memory,
savings,
they're
kind
of
in
review
and
we're
still
squeezing
a
bit
more
out
of
it.
We're
working
on
a
ui
development.
F
A
G
Hi,
so,
regarding
the
altair
hard
fork
for
now,
we
have
the
low
impact
and
preparatory
changes
merged
still
evaluating
the
modularization
of
the
code
base,
for
example
the
beacon
state.
The
main
thing
that
we
need
to
solve
is
that
currently
we
assume
that
we
have
a
kind
of
one
fork
at
a
time
design,
but
when
we
replay
all
states
around
the
transition,
we
need
to
be
able
to
handle
it
properly.
G
Otherwise,
we
improved
performance
of
nimbus,
so
we
had
some
bottleneck
real
related
to
planning,
and
we
also
added
attestations
batching
and
this
improved
performance
on
raspberry
pi
to
be
able
to
handle
the
increased
load
on
pyramid
and
hopefully,
a
pratter
as
well.
Regarding
prata,
we
also
added
a
prater
page
to
our
nimbus
book
and
we
also
merged
a
long-standing
feature,
request
fallback,
if
one
provider,
so
that
you
can
point
to
geth
and
also
insurer.
In
case
your
gif
instance
fails.
So
you
don't
have
any
issue
with
producing
blocks.
G
Otherwise,
we
also
finished
or
http
server
work,
because
in
name
we
didn't
have
any
http
secure,
http
server
that
was
working
with
or
stack,
and
so
this
means
that
in
the
future
you
won't
need
to
add
the
insecure
option
to
have
metrics,
and
this
also
means
that
the
rest
api
is
almost
finished.
It's
just
pending
review
and
you
won't
need
to
use
a
json
rpc
which
was
used
as
a
stop
gap.
And
lastly,
on
the
devops
front
we
will
be
migrating
or
flipped
away
from
aws
to
save
on
costs.
A
A
A
Moving
on
to
altair,
as
you
all
saw
alpha
3
was
launched.
I
actually
was.
I
realized.
I
did
something
embarrassing,
but
then
prototype
is
not
too
too
embarrassing,
but
I
I
realized.
I
started
at
alpha
one
instead
of
alpha
zero
and
actually
confused
myself
when
I
was
releasing
alpha
three
and
I
was
like
wait,
we
haven't
done
four
of
these,
so
anyway,
I
had
a
little
off
by
one
error
in
my
head,
but
that
is
out
that
is
really
close
to
honing
in
on
a
final
version.
A
I
I
think
there's
a
couple
of
cleanups
there's
some
additional
testing
being
done,
but
nothing
substantive
that
is
in
dev
currently,
and
the
plan
would
be
to
get
people
to
to
kind
of
get
thumbs
up
from
engineering
teams.
That
implementations
are
done
and
also
obviously
any
feedback
that
you
might
have.
So
we
can
hone
in
on
on
finalizing
that
we
are
at
kind
of
the
beginning
of
april.
We
had
discussed
doing
this
release
two
main
net
in
june.
That's
beginning
to
be
maybe
not
aggressive,
but
the
optimistic
timeline.
A
A
A
H
We
have
prepared
a
document
that
I
just
I
just
shared
the
link
on
the
chat
in
which
we
have
two
sets.
One
of
then,
we
call
the
minimal
set
it's
about
a
dozen
metrics
that
we
think
are
interesting
to
look
in
particular
in
the
context
of
the
proctor
test
set,
and
so
we
provide
the
list
of
the
metric.
The
description,
the
reasoning
and
we
look
at
four
of
the
five
clients,
and
I
think
at
least
for
the
first
batch
of
metrics.
All
of
them
already
implemented
them.
H
The
the
problem
is
that
they
just
have
different
names,
and
we
are
not
100
sure
that
this
is
what
it
really
is.
So
the
idea
is
to
really
start
with
just
these
few
ones
and
standardize
it
into
a
way
so
that
we
can
monitor
it
and
make
dashboards
and
and
really
see
easily
what
is
going
on.
So
what
it
would
be
really
great,
if
is,
if
you
know
the
different
plant
teams,
can
either
choose
or
select
one
person
that
can
help
us
with
this
process.
H
We
promise
to
take,
as
least
as
time
as
possible
from
you
guys.
We
know
that
you
are
very
busy
but
yeah
if,
if
we
could
try
to
set
some
call
in
which
we
can
discuss,
for
example,
which
of
these
metrics
are
the
most
relevant
and
if
the
numbers
that
we
sorry
the
metrics
that
we
got
here
are
correct
or
not
and
and
discuss
on
that
would
be
great,
so
yeah.
H
A
Right
for
one-
and
you
have
to
have
questions,
one
thing
I
want
to
reiterate
is
that
for
client
ease
of
client
fluidity.
I
think
we
did
a
good
job
with
the
validator
interchange
database,
but
one
thing
that
I
think
is
locking
people
in
and
hear
even
more
is
their
monitoring.
Setups
people
do
a
lot
of
work
to
get
things
set
up
and
monitored
properly,
and
then
don't
want
to
do
that
again,
and
this
could
potentially
enable
some
some
better
fluidity
there
leo
and
perry.
A
H
I
Yeah
sure
so
it
pretty
much
started
with
the
prata
setup.
I
wanted
to
create
a
bunch
of
dashboards
to
monitor
how
the
testnet
was
going,
but
quickly,
then
into
extensive
amount
of
having
to
look
at
three
or
four
different
documentations
to
figure
out
the
exact
metric
names.
So
I
looked
at
what
pain
points
were
there
and
what
metrics
were
relevant
for
me
to
know
that
stuff
is
working
perfectly
fine
and
I
just
sort
of
spoke
with
leo
discussed
them
if
he
was
also
on
the
same
page,
and
then
we
listed
them
down.
F
On
the
lighthouse
side,
we've
also
been
quite
interested
in
standardizing
metrics
to
enable
client
fluidity.
One
of
the
approaches
that
we've
looked
at
taking
is
there's
a
bunch
of
community
members.
I
guess
that
have
made
some
pretty
cool
dashboards.
I
forget
their
names
now,
but
there's
some
some
quite
popular
ones.
F
Typically,
they
work
with
prism,
so
the
approach
we've
been
taking
is
trying
to
get
these
dashboards
and
then
and
then
use
that
set
of
metrics
to
indicate
that
people
you
know
want
to
use
it
and
then
try
and
focus
on
those
first.
So
that's
that's
kind
of
the
route
we've
been
taking.
We
had
someone
on
that
full
time,
but
they
got
distracted,
but
I
think
they'll
get
back
onto
that
full
time.
So
lighthouse
is
keen
to
standardize
that.
I
F
Yeah
sure
so
something
I
found
with
metrics
is
that
it
varies
a
lot
depending
on
what
you
want
to
do.
So,
if
you're,
like
sitting
there
and
you've,
got
like
you
know,
two
main
net
validators,
there's
a
certain
amount
of
things
you
want
to
do.
If
you're
trying
to
monitor
the
health
and
network,
there's
the
things
you
want
to
do
and
if
you're
someone
like
me,
there's
a
whole
other
set
of
things
you
want
to
do
so
yeah.
F
It
is
that's
just
one
thing
that
I've
found,
but
I
think
there's
the
lighthouse
has
a
ux
channel
people
share
some
of
those
in
there.
I
think
cmonkey82
is
someone.
That's
made
a
good
one.
I
can
also
see
joeldock
has
tried
to
convert
it
over
to
lighthouse,
but
perhaps
the
prism
discord
just
reaching
out
there
and
seeing
what
people
are
using
is
a
good
idea.
H
Right
so
we
noticed
that
actually
most
of
the
clients,
they
already
have
a
number
of
metrics
that
are
already
common
to
all
of
them.
So
I
think
the
best
way
to
start
is
to
you
know,
to
decide
this
common
intersection
between
all
the
clients
or
at
least
most
of
the
clients
and
start
from
that
point.
So
I
think
in
in
the
document
we
added
a
small
table
where
you
can
have
other
contact
person
for
each
client.
F
L
Okay,
I'll
go
I'm
happy
to
share
that
the
new
full
choice
spec
is
ready.
This
has
been
in
the
works
for
a
few
months,
so
pretty
excited
to
share
that
it's
pr2292
on
the
spec
sleeper.
Please
do
check
it
out
and
leave
comments
and
feedbacks,
and
if
there's
something
specific
you
want
to
talk
about,
you
can
ping
me
or
danny.
L
The
summary
of
changes
for
this
pr
is
that
the
block
restructure
is
changed
and
the
way
that
latest
messages
are
accounted
for
has
changed
during
ghost
execution,
and
the
happy
news
here
is
that
there's
no
change
to
the
network
structures,
so
latest
messages
votes
remain
the
same.
The
way
latest
messages
are
structured
remain
the
same,
and
overall
this
has
good
security
and
good
performance
and
yeah.
L
M
L
A
M
L
A
At
least
until
we
are
done
with
the
transition
not
even
worth
that
complexity,
because
if
anything
you
like,
if
there
were
this
type
of
attack,
you
might
have
a
disagreement
for
some
short
amount
of
time,
but
even
justification
and
finalities.
Still,
it's
not
like
you're
removing
things
from
your
choice,
so
things
can
still
move
on.
A
A
I
that's
what
I
would
argue
yes,
but
we
can.
We
can
just
we
can
think
about
a
little
bit
more,
but
I
that's
my
understanding
is
that
we
can
it's
safe
to
roll
it
out
like
that
and
something
that
we
are
looking
for.
Specifically
as
you
look
at.
It
is
just
kind
of
like
sanity
check
that
engineering
complexity
and-
and
that
of
this
change
is
not
massive
that
it.
You
can
generally
kind
of
use
some
of
your
same
structures
and
algorithms
in
slightly
modified
way,
which
we
believe
in
this
case.
A
Not
for
real
today
right,
we
are
not
currently
planning
on
releasing
it
out
again.
It
is
a
it's
a
modification
of
the
phaser
rule,
and
so
once
we
do
have
it
inspect
and
we're
considering
it
for
merge,
we
can
have
the
conversation
we
can
re-up.
This
conversation,
maybe
offline
about
how
we
want
to
coordinate.
K
K
A
A
N
So,
besides
the
merge
call
next
week,
we'll
also
do
more
regular
calls
for
realism.
So
if
you're
interested
to
stay
in
the
loop,
you
can
attend
these
kind
of
office
hour
calls.
These
are
optional
and
you
can
hop
in
and
out
on,
the
discord
in
the
r
d,
discord
and
yeah
you're
welcome
to
to
help
with
the
early
merge
work.