►
From YouTube: Eth2.0 Call #63 [2021/5/6]
Description
A
A
A
A
The
agenda
is
issue:
20
217.,
nothing
crazy.
Today,
client
updates.
I
put
a
position
in
the
agenda
for
discussion
in
the
incident.
If
we
have
anything
else
to
discuss.
I
think
we've
discussed
this
a
ton
offline
and
there's
a
lot
of
like
public
updates
and
discussions
around
it.
But
if
anybody
hasn't
had
a
place
there,
altair
general
engineering
progress,
spec
in
testing
planning,
we're
going
to
research,
updates,
spec
discussion
and
any
closing
remarks.
Just
a
reminder.
A
B
B
A
Great
and
in
terms
of
the
validator
interactions,
it's
primarily
additive
as
long
as
you
have
the
data
structures
correct
and
that
I
guess
a
block
producer
could
do
the
same
role
and
just
not
be
paying
attention
to
those
sync
committee
and
similarly,
someone
could
just
not
pay
attention
to
their
security,
so
you
might
even
be
able
to
stand
up
a
testament
today,
but
great
progress.
Let's
move
on
to
lighthouse.
C
Hello
paul
here
so
when
it
comes
to
altair,
we
have
our
consensus
changes
awaiting
review,
we're
adding
some
caching
to
our
beacon
chain
for
sync
committee,
so
getting
the
the
fast
verification
of
that
down
pat
and
we're
also
going
we've
got
the
network
protocols
under
review,
then,
when
it
comes
to
rainism
we're
just
passing
the
merged
test
sectors.
Today,
generally
we're
aiming
towards
at
the
1.4.0
release.
C
It's
probably
going
gonna
be
the
next
few
weeks,
but
it
rolls
in
a
bunch
of
features
that
we've
been
working
on,
including
beta
window
support,
big
reduction
memory,
footprint,
doppelganger
service,
we're
reducing
our
outbound
f1
calls,
and
it
will
also
have
the
altair
structure,
definitions
and
the
the
the
mechanics
to
to
choose
between
the
two
forks.
That's
also
going
to
be
included
in
that
that
big
release,
so
it's
coming
in
a
few
weeks.
C
We're
also
planning
to
share
some
validated
performance
stats.
It's
not
comparing
clients,
but
it's.
You
can
compare
a
group
of
validators
just
to
the
global
average
for
some
span
of
time,
I'm
just
trying
to
try
and
get
the
the
broader
staking
community
to
be
a
little
bit
more
aware
of
the
details
of
how
their
annotation
rewards
go.
C
D
D
D
D
We
have
improved
our
nimbus
guide
in
a
lot
of
areas
following
feedbacks
from
especially
a
rocket
pool
users,
and
we
have
a
blog
post
called
if
two
is
green,
which
made
headlines
on
twitter,
especially
and
was
well
received.
Also
on
a
lot
of
discord-
and
that
was
with
gaff
plus
numbers,
plus
a
rocket
pool,
running
10
validators.
E
Hey
guys
parents
here
so
we
finally
merged
the
optimized
slasher
implementation
and
that
will
go
into
a
release
in
about
a
week
and
a
half
and
a
terrorist
fat
test
is
finally
passing
and
now
we're
working
on
optimization
of
sync
committee,
like
paul,
said
also
working
on
networking
and
the
validator
to
be
connect
interactions,
and
so
we
participate
in
the
merge,
the
the
testnet.
Unfortunately,
we
had
some
consensus
error
and
that
was
confirmed
using
the
merge
spread
test
product
put
out
yesterday.
So
thank
you
for
that.
E
A
F
Hey
guys
so
we're
pretty
much
caught
up
with
the
latest
alpha
spec
release
with
respect
to
altair
reference
tests
are
passing,
except
for
a
few
altair
state
upgrade
test
cases
that
we
need
to
debug.
All
the
sync
committee
related
validator
duties
have
been
implemented.
We
integrated
the
altair
state
upgrade
logic
so
that
we
can
transition
across
fort
boundaries.
F
F
This
isn't
in
an
official
release,
but
we
went
ahead
and
implemented
the
version
two
of
the
get
metadata,
rpc
request,
which
adds
a
new
sync
nets
field
and
we're
continuing
to
migrate.
Jim
mcdonald's
proposed
sync
committee
apis
to
the
standard
spec
and
implementing
those
within
tekku
as
we
go,
and
we
also
had
a
community
contribution
for
a
custom
rest
endpoint
to
query
peer
gossips
course,
and
that's
it
for
me.
A
A
Okay,
if
you're
listening
in
prism
has
a
great
incident
report
and
a
number
of
others
have
been
discussing
this
and
you
can
probably
easily
find
a
lot
of
that.
Thank
you
and
thank
you
for
everyone
that
worked
their
ass
off
through
the
weekend
on
that
one
altair.
So
we
got
general
engineering.
Progress
seems
like
things
move
forward,
not
too
much
issue.
I
did
want
to
have
another
pre-release
out
now-ish.
A
I
actually
had
eye
surgery
one
week
ago
and
was
a
little
more
optimistic
and
how
much
I
was
going
to
be
able
to
read
and
do
computer
work
in
the
past
week.
But
many
people
from
my
team
have
stepped
up
there's
a
lot
of
prs
out
for
kind
of
not
a
final
release,
but
a
wave
of
kind
of
cleanups
and
testing,
primarily
a
lot
of
a
lot
of
testing
to
be
added.
So
we
are
aiming
to
get
a
lot
of
that
review
done
today
and
try
to
get
respect
pre-release
out
tomorrow.
A
But
looking
at
his
proposed
changes,
I
don't
personally
think
it's
extremely
complicated.
I
think
we
could
get
a
reasonable
amount
of
test
factors
in
there
without
too
much
issue,
but
while
we
enhance
the
testing
the
next
couple
days
on
that
pr,
I
would
suggest
if
you
haven't
taken
a
look
in
your
client
team
to
take
a
look
at
that.
A
G
G
A
A
A
A
I
mean
I
guess
from
the
first
from
like
the
financial
analysis:
it's
probably
a
very
small
amount
of
money,
one
way
or
the
other,
and
so
but
a
reasonable
amount
of
dev
time.
So
that's
kind
of
a
funny
way
to
look
at
it,
but
there's
also
it's
definitely
probably
more
correct
in
the
sense
to
just
do
differentiation.
I
J
C
There's
also,
I
guess,
some
complexity
in
breaking
the
you
know
the
variant
that
you
know.
If
you
get
your
intestation
included
in
blocks
in
the
chain,
then
you
get
rewarded
and
and
that
these
you
know,
participation,
metrics
stay
the
same.
So
you
know,
I
guess,
there's
a
there's,
a
there's,
a
complexity
that
lives
there
too.
If
we
choose
not
to
address
it
in
the
spec.
I
C
A
A
I
A
I
I
J
Yeah,
I
think
one
of
michael's
point
sorry.
One
of
michael's
point
I
think,
was
that
a
lot
of
validators
will
actually
be
watching
this
quite
closely
that
particular
epoch
quite
closely
and
monitoring
their
rewards
and
noticing
that
they're
not
actually
getting
any.
Might
you
know
trigger
a
whole
heap
of
users
complaining
on
our
discord
channels
and
probably
but.
I
I
A
H
I
I
L
Think
the
issue
is
more
that
if
someone
sees
something
happen,
that's
unexpected,
they
trigger
a
retrospective,
they
trigger
a
dev
time,
they
start
investigating
and
if
they're
not
prepared
to
for
this
to
happen,
they
may
devote
you
know
hundreds
of
hours
of
engineering
effort
to
try
to
figure
out.
Why
did
they
miss
the
cpoc
and
it
turns
out
just
because
it's
a
little
bug
that
was
never
bothered
to
be
fixed,
they
didn't
know
about
it
can
be
that
I
think
that's
real.
L
A
A
A
question
of
complexity
and
there
are
four
or
five
teams
here
that
are
going
to
implement
that
complexity
and
ultimately,
I'd
like
to
hear
more
input
from
the
various
teams.
It
seems
like
the
lighthouse
team
is
keen
on
adding
this
amount
of
complexity
for
it.
But
I'd
like
to
hear
what
other
people
say.
C
K
M
A
A
M
A
A
Okay,
if
you
haven't
taken
a
look
at
the
open
pr,
please
take
a
look
at
the
opr.
It
represents
additional
complexity
to
solve
this
minor
issue
and
would
certainly
require
a
bit
more
testing
to
make
sure
that
we
can
get
that
for
transition.
Correct.
Let's
can
every
team,
please
take
a
look
at
it.
It's
a
simple
pr.
We
just
need
to
make
calling.
M
E
A
K
Yeah,
I
just
just
a
little
concerned
about
timing.
If
we're
punting
two
more
weeks
before
we
make
a
decision,
it
just
so
june,
is
definitely
kind
of
outright.
If
we're
going
to
run
a
six
week
or
so
test
net.
At
that
stage,
then
we're
sort
of
into
mid-july
and
we've
got
things
going
on
on
the
eth1
network
and
so
on
time
starts
slipping
away.
A
C
A
J
No
good
so
yeah
we're
spending
a
lot
of
time,
patching
youth,
chufas
and
basically
incorporating
the
latest
changes
of
various
clients
that
we
have
in
there.
So
that's
taken
actually
a
lot
more
time
than
I
anticipated,
but
that
timeline
will
probably
you
know,
work
for
us.
I'm
I'm
expecting
us
to
have
both
the
differential
fuzzing
and
the
coverage
guided
fuzzing
up
by
you
know
june
early
june.
So
hopefully
we
can
get
a
decent
amount
of
fuzzing
cycles
in
before
we
or
around
the
time
we'll
be
forking.
The
test
nets.
K
G
N
We
don't
have
a
release
out
just
yet,
but
so
yesterday
I
made
two
different
pre-releases
or
pre-releases
of
the
pre-release,
really
that
enable
all
the
client
implementers
to
move
to
go
ahead
and
test
the
merge
and
try
the
latest
alter
changes.
And
then
I
expect
like
end
of
this
week
or
maybe
like
start
next
week.
It
will
cut
an
official
release.
N
One
more
thing,
so
I'm
currently
writing
a
proposal
for
the
new
way.
I
would
like
to
handle
configuration
within
the
clients,
and
so
I
am
working
on
updating
the
specs
to
separate
constants
configuration
and
presets,
and
the
idea
here
really
is
to
try
and
separate
the
things
that
are
really
intended
for
test
builds
and
these
kind
of
more
static
configuration
things
and
separate
them
from
the
more
dynamic
things
that
we
change
with.
M
H
N
Right,
so
the
idea
here
is
that
it's
much
it's
less
scary,
to
try
and
change
the
configuration
for
different
test
nets,
and
you
can
rely
on
the
runtime
capability
of
clients
for
different
local
tests
and
test
nuts
and
then
settle
on
like
a
few
set
presets
that
change
more
of
the
configuration
for
testing
purposes
but
which
won't
have
to
you
won't
have
to
go
beyond
those
presets.
You
want
to
support
them
in
binary,
so
we
can
have
compiled
time
configuration
for
a
lot
of
things.
A
M
N
Right
so
I
think
we
should
maintain
the
minimal
preset
that
really
just
define
it.
Does
this
one
preset,
so
we
have
mainnet.
We
have
minimal
these
things,
only
change
during
compile
time,
and
then
we
do
specify
like
which
things
are
like
part
of
a
preset.
So
clients
can
opt
to
define
additional
presets,
but
we
don't
require
clients
to
define
more
than
these
two
spec
presets
and
we
just
try
and
isolate
the
parts
of
the
configuration
that
we
do
want
to
configure
as
a.
N
A
N
O
Yes,
any
craving
yep,
yep
yeah
so
used
to
quick
maintenance
quickly
mentioned
that
we
have
set
up
a
group
for
working
on
the
standardization
of
the
style
metrics.
So
I
would
take
this
opportunity
to
thank
the
client
teams
to
help
us
on
this
effort
and
we
are
starting
to
make
some
progress
into
selecting
a
subset
of
metrics
that
is
already
implemented
on
our
clients
and
trying
to
standardize
those
so
that
we
can
track
many
things
across
clients.