►
From YouTube: Eth2.0 Call #55 [2021/1/13]
Description
A
B
B
Thank
you
all
around
and
we
have
a
lot
of
work
to
do
and
a
lot
of
exciting
things
to
accomplish
this
year.
So
here
we
are,
I
flipped
it
a
little
bit
today.
I
think
we'll
start
with
client
updates.
Then
we'll
talk
about
a
proposed
mid-year
upgrade
and
some
of
the
things
there.
I
think
there
are
a
couple
of
proposals
floating
around.
B
We
need
to
get
this
kind
of
written
up
in
a
more
concrete
way,
so
we
can
engage
with
it
better,
but
there
are
some
some
pr's
in
the
repo
that
I'd
like
some
input
on.
We
can
get
to
that
a
little
bit
later.
Then
I
want
to
just
kind
of
give
you
the
broad
on
q1,
r
and
d,
which
will
kind
of
I
think
client
teams
can
dip
their
toes
in.
B
Do
some
education
here
and
some
some
input
which
will
help
set
the
stage
for
upgrades
kind
of
expected
in
the
latter
part
of
the
year
and
early
next
year,
and
then
we
can
talk
about
just
some
general
stuff
and
see
where
we're
at
so.
Let's
go
ahead
and
get
started.
We
can
start
with
client
updates
and
teku
get
started.
A
We
incorporated
the
recent
risk
api
updates
to
the
debug
state
endpoint,
so
we
now
return
the
requested
state
as
json
or
ssc.
Depending
on
the
accept
header.
We
reworked
our
validator
client
to
optionally
use
the
dependent
root
fields
which
were
added
just
before
mainnet
to
detect
when
duties
need
to
be
invalidated.
A
We've
reviewed
the
upcoming
protocol
upgrade
changes
and
have
started
some
refactoring
to
prep
for
it,
and
we've
been
doing
some
general
cleanup
bug
fixes
because
to
get
performance,
tests
up
and
run
running
some
hardening
of
the
p2p
layer
and
some
code
quality
related
refactoring.
That's
it
for
me.
C
B
C
Well,
we
have
kind
of
configure
parameters
for
advanced
users,
but
so
far
our
thinking
thinking
is
to
make
this
really
simple
for
end
users,
and
we
don't
offer
many
options
just
either.
You
have
the
protection,
you
don't
have
it
gotcha.
Our
parameter
is
hidden
so
far,
and
we
are
also
deploying
this
right
now
in
production
in
a
special
mode
where
it
produces
only
a
warning.
So
our
thinking
here
is
that
we
want
to
make
sure
that
there
won't
be
any
false
positives.
B
D
E
E
F
Hello,
so
we've
been
coordinating
as
a
team
to
determine
how
we
can
best
apply
ourselves
to
the
phase,
zero
maintenance
and
also
the
shutting
and
merge
works.
I've
written
a
blog
post
about
this
with
our
intentions
and
we
should
be
releasing
it
next
week
since
the
last
score,
we've
published
a
few
releases
lots
of
fixes
and
improvements.
There,
we've
added
a
new
system
for
monitoring
validators,
that's
in
a
pr
now.
F
So
this
is
on
the
beacon,
node
side.
It
has
a
list
of
validators
and
it
performs
additional
logging
when
your
evaluator
has
a
block
included
or
a
test
station
included.
It
has
a
lot
of
prometheus
metrics
to
do
like
fine
training
tracking
of
front
grain
tracking.
Your
validators,
like
the
delay
when
you're
getting
their
attestations
and
blocks
and
things
so
you
can
supply
the
beacon,
node
manually,
a
list
of
validators
to
track
or
you
can
get
it
to
detect
them
automatically
by
subscription
calls
to
the
api.
F
That's
doing
the
pr,
but
we
should
see
it
soon.
We're
adding
support
for
weak
subjectivity.
Sync-
and
this
turned
out
to
be
quite
nice,
since
it's
making
our
database
more
flexible
and
generic
we've
been
reviewing,
the
media
upgrade
prs
and
thinking
a
lot
about
how
we
can
best
support
hard
forks
with
minimal
code,
duplication
and
complexity
and
we're
also
thinking
about
how
we
can
support
the
sharding
and
merge
experimental
works
inside
the
lighthouse
repo
without
you
know,
jeopardizing
the
stability
of
the
production
code.
That's
about
it
from
us.
G
We
also
refactored
our
request
and
response
code,
which
will
help
us
revisit
our
syncing,
so
concurrently
we're
working
on
updating
the
sync,
so
we
can
like
download
and
process
blocks
in
parallel.
It's
a
lot
better
to
do
that,
and
we're
also
now
shifting
some
of
our
team
to
be
looking
at
future
hard
forks.
So
we've
been
looking
at
how
to
update
our
database
to
more
easily
support
hard,
forks
and
different
types
of
data,
and
we
are
planning
our
next
release
for
monday,
with
all
of
the
things
that
we've
done
so
far.
H
Hey
guys
happy
new
year,
and
so
in
the
last
couple
weeks
we
have
made
our
slashing
protection
on
validated
on
the
validated
client
side,
more
performant,
it's
working
better
without
the
decline
that
holds
over
more
than
hundreds
of
keys.
This
is
on
track
for
version
1.1
release
next
monday,
and
we
also
have
a
bunch
of
box
fixes
that
has
gone
into
the
release
and
then
on
the
e2
api
implement
implementation
side.
We
are
almost
done
with
the
now,
with
the
networking
stack
in
parallel.
H
B
B
This
currently
is
in
the
form
of
some
pr
proposals
and
stuff
in
what's
called
the
light
client
spec
folder.
That
would
be
renamed
to
be
the
name
of
whatever
this
upgrade
ends
up
being
called
and
generally.
I
think
we
want
input,
especially
on
some
of
the
state
reform
stuff
from
engineering
teams,
because
this
ultimately
should
make
things
cleaner,
but
also
might,
depending
on
the
path
taken,
represent
technical
debt.
So
we
kind
of
want
to
find
the
right
balance
here.
So
please,
please.
B
There
are
a
couple
of
pr's
up
for
review,
accounting
reform
and
global
penalty
quotient.
These
are
probably
the
two
more
invasive
things
with
respect
to
state
and
management
and
validators,
but
would
love
for
you
to
take
a
look.
The
other
big
one
there
is
which
is
already
in
dev.
Under
that
light,
client
folder
is
adding
this
notion
of
a
sync
committee,
which
is
a
very
similar
to
a
beacon
committee,
but
larger
and
longer
standing.
B
That
proposers
can
include
the
signature
of
which
they
just
kind
of
sign
over
the
latest
block
and
what
that
does
is
provide
like
client
support,
kind
of
as
a
first
class
citizen,
in
addition
to
some
of
the
beacon
chain
changes
to
support
that
feature.
There
is
a
sync
protocol
file
which
demonstrates
how
you
can
use
this
to
construct
a
liteclasing
protocol.
Analyte
client,
that's
reuses,
a
lot
of
the
components
that
we
already
have
the
notion
of
committee,
subnets
aggregate
signatures,
that
kind
of
stuff,
and
it's
a
really
a
big
win.
B
B
Good
features
to
get
in
there
beyond
that.
There
are
a
couple
of
like
network
iterations
network
fixes
that
are
coming
out,
which
I
believe
should
be
released
prior
to
such
a
fork
and
a
couple
of
security
fixes
to
the
fork
choice
which
are
under
some
internal
review.
Right
now-
and
I
will
share
those
with
you
once
we
have
concrete
proposals
which
should
be
in
the
next
week
or
so
that
too
can
be
released
prior
to
this
kind
of
mid-year
upgrade
and
probably
should
be.
B
On
all
of
that,
I'm
happy-
you
know
open
up
for
discussion
here
and
also
take
the
discussion
to
the
repo.
I
think
we
need
to
figure
out
how
to
kind
of
package
all
of
this
for
discussion
and
review
other
than
just
hammering
out
these
pr's
and
the
spec
repo,
and
obviously
that
can
be
a
bit
opaque
so
in
the
next
week
or
so
I'd
like
to
get
you
know
this
just
written
down
kind
of
bulleted,
at
least
in
some
form.
So
we
can
talk
about
it
in
aggregate
better.
B
Any
questions
or
discussion
on
that.
This
also
serves
as
something
of
a
warm-up
gets
our
hands
dirty
in
being
able
to
upgrade
the
beacon
chain
in
a
production
context.
I
was
going
to
have
to
you
know
about
to
do
that
on
test
nets
and
then
do
that
on
mainnet
before
a
couple
of
the
more
ambitious
and
larger
upgrades,
which
would
be
the
merge
and
charting
further
down
the
line.
G
Right,
I
guess
one
thing
to
add
is
that
the
ideally
we
want
to
kind
of
come
to
consensus
on
like
what
we
what
we
wants
to
go
into
heart?
Well,
I
guess
what
we're
calling
hard
fork
one
kind
of
fairly
quickly
just
so
that
we
don't
need
to
lose
any
lose
any
time
on
moving
forward
on
it.
So
I'm
not
in
the
list
of
kind
of
items
that
can
potentially
go
in.
G
So
that's
three
and
then
also
fork
choice,
changes,
there's
two
tweaks
to
resolve
some
of
the
issues
that
people
have
come
up
with
over
the
and
published
some
papers
about
over
the
last
few
months,
but
like
I
guess
this
will
be
written
on
work.
Well,
this
is
these.
Things
are
already
in
the
issues
and
there's
already
some
documents
about
specific
things,
but
we'll
come
up
on.
B
B
B
E
E
Have
you
looked
at
how
much
of
that
processing
is
really
in
the
spec
like
in
the
spec
function
and
how
much
of
it
is
due
to
finality
occurring
and
therefore
clients
needing
to
prune
trees,
save
databases
and,
and
things
like
this
across
the
board,
I
mean,
I
know
from
nimbus
like
we,
the
the
difference
between
processing,
a
block
and
processing
an
epoch.
Isn't
that
significant?
If
we
only
consider
the
part
in
the
state
transition.
G
B
Yeah,
I
mean
any
numbers
from
clients
on
that
would
be
great.
Additionally,
it
also
make
there's
two
other
wins.
One
is
throughout
the
epoch.
The
state
actually
makes
it
is
much
more
aware,
informationally
about,
what's
going
to
happen,
which
I
think
could
help
serve
users
and
more
sophisticated
apis,
and
it
actually
makes
spec
writing
and
spec
reasoning
simpler.
B
I
guess
another
thing
to
note
is
that
the
validator
set
size
is
probably
going
to
grow,
so
optimizations
here
are
valuable,
but
you're
right.
A
lot
of
the
optimizations.
A
lot
of
what
this
reform
does
is
takes
some
of
the
the
way
things
are
cached
and
optimized
on
epoch
transitions
today
and
actually
just
kind
of
chucks
it
into
state.
As
canonical.
F
E
Well,
I
can.
I
can
just
briefly
mention
that
I
know
from
from
from
experience
in
left
numbers
that
our
slowest
processing
is
definitely
persisting.
The
state
on
finalization
and
on
epoch,
transitions
really
like
that.
Just
so
massively
outweighs
everything
else
that
that's
what
we're
focusing
on
right
now
with
you
know,
with
more
clever
ways
of
of
storing
the
state
so
that
we
don't
duplicate
as
much
information
every
time,
but
that's
going
to
be
highly
client
dependent.
I
suspect
right.
F
Yeah
the
nice
thing
about
the
accounting
reform,
one
is
that
it
makes
a
little
bit
easier
to.
I
think
it'll
make
it
easier
to
optimize
the
database
because
you're
storing
this
kind
of
list
of
of
of
bits
that
it's
quite
easy
to
reason
about
versus
a
list
of
weird
attestations
that
are
quite
you
know,
it's
really
hard
to
compress
them.
So
I
think
I
think
it'll
be
handy
in
the
long
run.
B
B
There's
some
prototypes
and
even
miguel
has
some
like
local
test.
That's
running
on
the
merge
stuff,
I
think
in
terms
of
client
resourcing
there's
stuff
to
dig
into
here
which
can
help
the
r
d
effort
and
help
spec
effort
and
help
refine
these,
and
then
I
think
the
goal
would
be
to
at
the
end
of
q1
have
a
pretty
good
handle
on
both
have
something
looking
like
pretty
good
specs
on
both
and
being
able
to
at
that
point,
make
a
decision
on
what
to
drive
on
more
concretely
in
production
engineering.
B
B
I
think
the
teams
here
to
help
schedule
something
there
and
I
think,
just
in
general,
dig
into
what
the
resources
are
so
far
and
start
thinking
about
it,
providing
feedback
and
thinking
about
what
your
team
can
do
to
engage
with
it
to
help
refine
both
of
those
it's
a
bit
long-winded.
Essentially,
we
have
merge
work.
B
We
have
sharding
work
both
are
in
like
heavy
r
d
and
kind
of
in
the
early
spec
phases
and
testing
and
we're
working
actively
to
refine
them
and
can
use
help
at
the
same
time
bring
you
up
to
speed.
I
know
everyone's
been
pretty
heads
down
on
on
shipping
the
beacon
chain
and
there's
some
fun
stuff
to
learn
about
and
start
engaging
with.
B
I
I
B
Right
so
we've,
I
think,
up
to
this
point
been
relatively
quietly
working
in
you
know
a
working
group
and
driving
on
this,
and
I
think
it's
it's
definitely
time
to
compile
what
we
have
worked
on
into
digestible
information
and
also
kind
of
opening
up
this
working
group.
So
we're
not
just
working
in
a
silo
and
welcoming
moran.
B
B
B
B
B
B
K
K
I
think
we
want
to
try
and
keep
you
know,
keep
making
progress
internally
at
ef
in
terms
of
of
specking
and
prototyping,
but
maybe
limit
the
the
expectation
that
implementers
have
to
understand
all
this
stuff
and
and
and
and
be
on
top
of
things
and
and
implement
it
in
the
short
term.
So
I'm
I'm
hopeful
that
kind
of
this.
B
Here
great
networking
age
put
up
an
issue.
There
is
in
the
way
we
do
aggregate
attestations,
there's
this
optimization
in
the
validations,
so
that
you
ignore
an
aggregate
attestation
if
it
has
the
same
exact
aggregate
if
it's
essentially
the
same
attestation
but
different
aggregator
this.
Actually,
this
was
a
nice
to
have
optimization
that
ultimately
actually
makes
more
work
on
the
network
today,
because
all
the
message
id
is
actually
related
to
the
outer
message
and
not
that
interactive
station,
and
so
you
end
up,
everyone
has
different.
I
want
I
haves
for
these.
B
What
look
like
the
same
aggregate
message
and
you
halt
the
gossip
on
the
repeats,
but
you
end
up
wasting
a
bunch
of
energy
on
I
want.
I
have
to
recover.
So
take
a
look
at
age's
issue.
It
explains
it.
Ultimately,
the
optimization
is
a
nice
to
have,
and
it
probably
makes
sense
to
remove
that
that
line
unless
there
is
a
like
clean
way
to
to
keep
that,
obviously
in
which,
based
on
a
little
bit
of
back
and
forth
between
me
and
age,
I
don't
know
if
there
is
at
least
well.
I
want.
B
B
E
B
I
yeah
I
mean
I
think
that
that's
a
valuable
conversation
to
have
is
especially
in
some
of
these
transient
attestation
channels.
It
might
not
be
helping
us
that
much.
That
said,
I
think
if
we
reduce
the
number
of
message
ids,
that
we
include
in
ihave,
I
want
and
rely
on
each
node
kind
of
randomly
sending
some
of
them
that
we
greatly
reduce
the
overhead
of
there
and
still
get
a
lot
of
the
benefit.
B
E
B
Right,
if
you
select
five
of
them
and
everyone
selects
five
of
them
and
you
have
100
peers,
there's
500
of
them,
but
coming
from
all
different
directions.
I
guess
that's
not
the
right
assumption,
because
people
aren't
different
subnets,
but
there
is
a.
There
is
potentially
a
play
at
getting
some
value
out
of
it
with
some
randomness.
But
look
I
hear
you
I
if
somebody
wants
to
quantify
what
I
want-
and
I
have
is
doing
for
us
today
on
mainnet.
That
would
help
us
make
a
decision
here.
B
B
L
B
B
L
I'm
not
hearing
anything
particularly
negative
about
piermont,
I
mean
it
does
occasionally
stumble,
but
this
this
is
fine.
It
seems
to
be
serving
those
needs
just
trying
to
get
a
sense
of
clarity
for
planning.
You
know
for
people
like
infuria
want
to
know
where
they
stand
if
they
adopt
peer
month,
whether
they're
gonna
have
to
adopt
something
else
straight
away
and
stuff
like
that
right.
B
One
way
to
potentially
keep
paramount
in
check
is
as
a
function
of
community
that
joins.
You
know
we
we
join
in
a
similar
ratio
with
validators
we
control
to
kind
of
keep
something
like
75
to
80
in
our
control.
I
don't
think
we've
added
any
validators
in
a
long
time.
We
could
consider
doing
so.
That'll
also
bump
the
load
up
a
little
bit
on
the
network,
which
would
be
good
for
testing.
M
One
one
minor
point
is
that
any
large
players,
like
exchanges
or
stuff
who
want
to
do
testing,
are
not
going
to
be
able
to
use
pure
mod
today,
in
all
likelihood
just
because
if
they
want
to
test
set
up
similar
to
what
they
will
eventually
go
on
maynet.
But
my
inclination
there
is
just
kind
of
make
them
keep
them
waiting
because
they're
may
not
necessarily
yeah
it's.
It
doesn't
seem
like
super
high
priority.
So
when
things
get
sorted,
they
get
sorted.
B
B
F
I
think,
if,
if
exchanges
and
these
big
players,
if
they're
actually
expecting
to
have
a
really
decent
chunk
of
validators,
then
I
think
perhaps
we
should
be
open
to
spinning
one
up
for
them
just
to
protect
our
own
interests
as
clients.
By
ensuring
you
know
this
good
two
thousand
validators
run
well,
so
I
don't
know
if
there's
any
big
big
players
out
there
listening,
then
they
can
approach
me
at
least,
and
we
can
just
spin
you
up
a
test
net.
We
used
to
do
it
all
the
time.
B
B
B
Great
well,
thank
you.
Everyone
please
have
someone
on
your
team.
Take
a
look
at
the
open
prs
that
we'd,
like
engineering
feedback
on
please
begin
to
dig
into
sharding
and
emerge
resources
to
bring
yourself
up
to
speed,
and
we
will
talk
to
all
in
two
weeks
and
then
do
some
sort
of
educational
information
exchange
workshop
shortly
after.