►
From YouTube: Eth2.0 Call #69 [2021/7/29]
Description
A
Okay,
yeah
welcome
everyone.
Danny
is
not
here
today,
so
I'll,
be
facilitating
a
call
and
let
me
pull
up
the
agenda,
but
I
know
the
first
thing
was
the
the
devnet,
so
it
seems
like
it
went
pretty
well,
there
might
be
some
minor
bugs
with
block
production
and
the
sync
aggregation,
but
otherwise
we
successfully
forked
the
devnet
it
looks
like
and
yeah
building
a
chain
was
there
anything
in
particular.
Anyone
wanted
to
add
to
that
right.
Now.
B
C
A
B
Hello,
everyone,
so
we've
been
working
a
lot
in
our
1.5.0
release.
We
published
a
blog
post
last
week
which
details
the
features
it
will
contain
else.
Our
progress
is
coming
along
well,
1.5.0
will
have
altered
testnet
support
out
of
the
box,
we're
also
working
on
testing.
Some
new
upgrades
to
our
networking
stack,
there's
been
one
last
rare
bug,
we've
been
hunting,
but
luckily
we
managed
to
get
a
back
trace
on
it
in
the
in
the
last
couple
of
hours,
so
we'll
be
climbing
through
the
function
call.
So
I'm
tracing
that
one
down.
B
So
that's
a
good
sign.
You
can
expect
to
see
a
1.5.0
release
candidate
in
the
next
week
or
two
and
after
we
get
1.5.0
out
we'll
start
working
on
the
next
release
and
that
should
contain
weak
subjectivity,
sync
remote
signer
and
some
nice
cpu
savings
looking
at
perhaps
an
order,
a
40
reduction
on
fraud
or
cpu
usage.
D
E
Next,
let's
do
prism,
hey
guys,
terence
here,
so
we
released
version
1.4.2
last
week
and
it
has
the
awesome
doppleganger
feature
feature
so
encourage
people
to
try
out,
and
they
also,
most
importantly,
contains
updates
for
the
london
hall
fort.
So
don't
forget
to
update
it
before
next
week
and
then
other
than
that
most
of
our
resources
are
on
a
tear
optimizations.
E
E
F
F
F
A
G
Yeah
hi,
so
we
put
out
our
21.7.0
release
this
week.
It's
got
mostly
just
a
few
bug
fixes
couple
of
things
we've
mentioned
before
that
now,
actually,
in
the
release,
the
main
one
is
a
file
handle
leak,
jpm
led
p2p
bit
of
a
corner
case
there
that
slowed
the
file
handles.
So
that's
cleaned
up
coming
up
so
still
in
the
in
in
the
development
branch
is
a
whole
bunch
of
changes
to
discovery
as
well.
G
That's
looking
pretty
good
and
starting
to
investigate
improvements
around
how
we
store
historical
state,
so
we
can
create
that
faster,
plus
a
whole
bunch
of
little
cleanups
and
getting
ready
alto
y
is
probably.
The
only
thing
is
that
we
now
support
the
contribution
and
proof
event
on
the
on
the
events
endpoint.
I
A
A
A
So
yeah
next
we
can
move
to
planning
and,
like
paul
kind
of
said
earlier,
perhaps
you
know
we
moved
to
a
more
asynchronous
thing
here,
but
yeah
does
anyone
have
any
any
thoughts
there?
I
think
we
wanted
to
see
how
devnet
2
went
and
it
sounds
like
we
want
a
devnet
three.
So
that
might
push
back
I'll
tear
itself,
but
you
know
that's
something
we
all
need
to.
B
G
Yeah,
I
mean
we're
consistently
seeing
the
transition
work.
Well,
the
piece
we're
not
seeing
is
the
perfect
inclusion
rates
on
on
sync
committee
signatures.
I
I
think
I'd
be
tempted
to
to
push
it
out
to
piermont
at
this
point
and
get
that
feedback,
given
that
we
want
to
kill
pim
on
after
this
anyway.
So
if
we
really
decide,
we've
got
to
make
massive
changes,
it's
not
the
end
of
the
world,
but
it
just
gives
us
a
somewhat
more
realistic
use
case
to
see
you
know
how
inclusion
goes
on
some
committees,
and
so.
B
B
A
G
Yeah
I
mean
in
terms
of
in
terms
of
the
fall
for
pyrmont.
I
think
it
needs
to
be
probably
at
least
a
couple
of
weeks
out
anyway,
because
we
need
to
get
that
the
config
for
pm
updated
in
each
client
and
a
release,
so
everyone
has
to
get
a
release
out
and
then
we've
got
to
convince
users
to
upgrade
or
it'll
just
go
into
non-finality
and
kind
of
cause,
chaos
just
because
people
didn't
upgrade
more
than
because
there's
a
problem
with
the
fork.
E
A
B
Yeah
totally,
if
it's,
if
it's
useful,
I
don't
mind
like
if
we
want
to
spin
up
another
devnet
next
week,
I'm
I
don't
mind
doing
that.
It's
fairly
low
input
on
my
end-
maybe
I
just
won't
stay
up
for
it,
but
we
could.
We
could
spin
one
up
if
that's
going
to
be
useful
to
anyone
for
having
problems.
I'm
happy
to
do
that.
So.
A
H
A
Okay,
so
it
sounds
like
maybe
devnet
three,
maybe
we
don't
need
it.
I
guess
we'll
look
more
at
that
two
from
this
morning
and
have
a
better
idea
and
we
can
discuss
that
asynchronously
and
then
it
sounds
like
there's
rough
consensus,
around
pyramid.
Four
can
say
three
weeks
once
we've
gotten
some
more
debugging
updates
and
and
releases
into
clients,
and
then
that
push
to
users.
So
everyone's
aware,
and
then
we
can
do
that.
A
A
A
H
On
that,
at
first
eap,
3675
has
been
merged
recently,
thanks
a
lot
for
ap
editors
to
give
it
a
green
light,
it's
in
a
draft
status
anyway,
so
it
will
be
definitely
updated
further
and
more
clarification
will
be
added
on
demand.
There
is
already
a
follow-up
discussion
in
the
pr
thread
regarding
some
points.
H
H
H
A
A
A
B
Just
regarding
the
forking
altair,
it
might
be
handy
to
have
like
maybe
estetica
could
be
involved
in
this
or
something,
but
it
might
be
handy
to
have
just
a
resource,
that's
a
table
of
all
the
clients
and
which
version
you
need
to
be
on
for
the
altair
fork.
This
is
for
piano
that
is
and
whether
or
not
that
version
has
been
released
or
yet
or
not.
G
B
A
H
I
One
we
probably
also
will
have
in
a
month
or
or
so
defined
is
general
radius
as
as
the
tolerance
loads,
the
state
from
from
the
anchor
state.
But
I
would
like
to
trust
the
other
teams.
What
what
were
the
main
things
that
you
found
in
the
this
week's
objective
implementation,
as
as
far
as
I
know
you
need
you
need
the
back
syncing
of
the
old
blocks
before
the
before
the
state
that
you
load
and
is
there?
Is
there
anything
else
that
needs
to
be
done
during
this?
G
One
of
the
surprise
things
is:
you
need
to
check
the
signatures
when
you're
doing
the
back
syncing
of
blocks
because
they're
not
included
in
the
hash,
but
otherwise
I
think
it
was
fairly
straightforward.
I
mean
you
know
as
much
as
anything
ever
is,
but
nothing
nothing
surprising.
It's
just
being
able
to
start
from
the
state
and
go
forward
from
there.
I
G
G
It's
it's
a
little
optimistic
and
that
we
can
get
a
few
batches
from
different
gears
at
the
same
time
and
then
check
our
lineup
and
that
kind
of
stuff.
But
but
ultimately
it
lets
you
not
download
too
many
blocks
from
the
wrong
branch
before
you
discover
that
it
doesn't
actually
line
up
with
the
state.
You've
got.
G
I
G
I
Okay,
but
theoretically,
I
believe
that
it
would
be
possible
to
to
make
a
a
different
chain
which,
let's
assume
you
got
a
wrong
snapshot
from
from
an
attacker
and
you,
you
probably
would
be
able
to
end
up
with
a
different
genesis,
not
the
the
the
main
one
or
the
community
one.
I
do
theoretically
possible
all.
G
G
Kind
of
the
same
thing,
so,
if
if
the
checkpoint
you
have
is
within
the
week
subjectivity
period,
then
yes,
you
could
verify
fully
from
there
that
you
ultimately
want
the
state
from
there.
So
you
can
actually
verify
the
block
transitions
board,
but
the
the
checkpoint
state
you're
starting
from
is
the
checkpoint
like
it's.
It
is
the
one
known
state
that
you're
being
told
this
is
on
the
chain.
G
You
can't
easily
trust
stuff
before
that,
because
it,
you
might
have
had
bad,
ladies,
that
have
exited
and
withdrawn
all
their
funds
and
then
sign
a
completely
valid
looking
chain.
So
there's
there's
a
number
of
heuristics.
You
can
do
to
start
detecting
that
and
so
on.
But
ultimately
your
key
thing
is
that
you
want
to
start
from
a
state,
that's
known,
to
be
valid
within
the
week
subjectivity
period,
and
you
can
do
that
either
with
a
state
or
with
a
root
hash
and
where
you
get.
G
I
G
So
then,
you
can
be
led
astray
by
validators
that
are
exited
because
because
of
the
weak
subjectivity
I
mean
some,
not
enough.
Validators
have
exited
yet,
but
theoretically
it
could
have
happened
by
now.
I
think-
and
certainly
at
some
point
in
the
future,
it
will
become
a
possible
attack
that
that
you
can
have
a
chain
made
up
of
signatures
where
you
have
nothing,
that's
slashable,
which
makes
two
completely
valid
chains.
G
G
Yeah
and
the
rest
of
things
is
just
details
so
making
sure
that
your
client
is
able
to
handle
rest
api
requests
from
before
you
have
any
states,
so
there's
a
whole
bunch
of
rest
apis
that
you
can't
answer,
because
you
don't
have
a
state
for
turkey
that
was
natural
because
we
have
a
mode
that
will
prune
anything
any
finalized
states
anyway.
To
save
this
space.
G
The
operation
like
in
terms
of
tracking
the
head
of
the
chain
and
performing
validated
duties
and
participating
in
in
network
you
don't
need
any
states
prior
to
the
latest
finalized.
You
do
need
to
backfill
those
blocks
at
the
moment.
Hopefully,
once
all
clients
support
checkpoint
sync,
then
we
can
not
necessarily
download
all
the
blocks,
but
there's
then
questions
around
who
is
storing
them.
Are
they
going
to
be
lost
forever
kind
of
thing,
and
so
there's
some
other
problems
to
solve
there.
I
I
A
A
Nothing
written
down,
but
yeah
basically
just
start
from
the
state
and
then
work
your
way
backwards,
but
it
is
very
important
I
would
say
to
backfill
and
it
you
know
it's,
I
think,
even
kind
of
on
us
to
like
say
that
we
have
the
norm
that
you
should
backfill
because
then,
like
adrian,
was
kind
of
into
that.
You
might
have
this
huge
problem
where
suddenly,
no
one
has
the
blocks,
and
I
don't
think
we
want
to
get
to
that
state.
G
Yeah
I
mean
in
terms
of
how
it
all
works.
The
whole
spec
is
is
designed
to
be
able
to
take
a
state
and
a
block,
and
you
can
always
apply
it.
So
it's
kind
of
nice
that
there's
no
real
reason
to
start
from
genesis
in
terms
of
what
you
have
in
your
client.
You
just
don't
need
it,
but
yeah.
Absolutely,
please
do
back
for
blocks,
don't
make
it
optional,
don't
even
provide
a
flag
to
not
do
it
just
just
do
it
it'll
be
good
for
the
network
at
the
moment.
G
Yeah,
absolutely
there's
a
there's,
a
chicken
and
egg
problem.
That's
been
going
on
for
a
while
here
in
that
we
didn't
support
checkpoint
sync
in
a
lot
of
clients,
because
there's
nowhere
to
get
checkpoints
states
from
and
it
was
a
real
pain
to
start
with
now
that
infuria
is
providing
it
it's
kind
of
centralized
which
isn't
it's
an
ideal
we'd
like
more
than
just
them,
but
at
least
it's
a
starting
point,
so
small
clients
start
supporting
it.
It
becomes
more
viable
for
everyone
to
do
it,
hopefully
more
places
to
get
it
from.
G
H
B
G
No,
you
can
do
it
without
creating
the
states,
in
fact,
there's
no
way
to
create
older
states
when
you
start
from
before
the
checkpoint.
You
start
with.
You
can't
run
the
process
backwards.
Basically,
but
it's
it's
just
verified
with
the
validators
public
key
which
you
can
get
from
the
current
state,
because
we
never
lose
them.
G
I
I
A
Some
of
these
things
we've
been
discussing
around,
like
you
know
these
longer
term
projects
around
serving
historical
state
are
super
important,
I'd,
say
they're,
like
parallel
streams
of
work
but
yeah.
Until
then,
you
can
store
everything
they
can
and
yeah,
maybe
down
the
line,
there's
different
sync
modes
or
pruning
modes
that
you
know
drop
state
before
the
merge,
but
we're
not
there.
Yet.
K
G
I
I
K
G
K
K
G
A
Yeah
and
I'm
just
going
to
add
it's
almost
a
bit
of
an
api
issue,
but
yeah
I
mean
the
more
I
think
about
it.
The
more
I
do
see
the
conflict,
so
one
thing
we
could
say
is
like
hey.
This
is
a
slot
number
on
the
beacon
chain
and
then
we
can
keep
the
block
numbers
as
they
are
on
the
execution
chain,
but
yeah.
That
is
a
good
point.
B
K
Of
all
block
numbers
have
a
prefix
basically,
which
indicates
where
they're
from
we
keep
a
list
somewhere
of
you
know:
prefix
one
billion
is
execution,
client
and
free
or
prefix.
Zero
is
executing
client
prefix,
one
is
client,
prefix
two
is
shard
n
and
then
these
prefixes,
just
you
know,
are
a
billion
plus
whatever
the
actual
block
number
is
so
that
way,
when
you're
seeing
a
block
number,
it's
always
a
big
number,
but
it
always
starts
with
kind
of
a
hint
as
to
what
kind
of
block
number
it
is.
I
M
K
Users
are
going
to
end
up
incredibly
confused
when
you
have,
you
know,
block
number
five
slash,
seven
like
what
is
that
like
for,
for
users
would
be
nice
if
there's
an
easy
way
when
they're
communicating
with
each
other
and
when
websites
present
data
to
them
there's
an
easy
way
to
identify.
Oh,
this
is
a
consensus
block
or
oh.
This
is
an
execution
block.
G
G
We'll
probably
have
some
apis
that
let
you
query
by
execution
height,
but
it
potentially
maps
to
multiple
beacon
blocks,
but
all
the
all
the
challenges
in
backwards
compatibility
and
making
this
understandable
to
users
is
really
going
to
be
the
execution
clients.
So
I
wonder
if
if
this
is
something
to
bring
up
tomorrow
on
core
devs
more
than
here,
because
they've
got
the
context
and
the
actual
ability
to
do
something
about
it,.
K
K
G
If
you
change
it,
you've
got
a
simple
division
prior
to
this
number
and
then
a
bunch
of
plots
that
don't
exist
at
all.
It's
weird
and
then
a
simple
division:
okay
from
a
different
genesis
route,
so
it
kind
of
at
some
point.
We
maybe
wind
up
doing
that
if
we
ever
change
the
slot
time,
but
if
we
can
put
it
off
as
long
as
possible,
it'd
be
really
nice.
B
Okay
yeah.
I
would
also
say
that
skipping
forward
the
slots
is,
is
going
to
be
really
complicated.
The
spec
the
f2
spec
relies
a
lot
on
the
idea
of
the
current
epoch
and
the
previous
epoch
epoch
being
32
slots
and
to
have
gaps
in
that
is
going
to
be
super
edge
casey.
I
can
just
imagine
heaps
of
clients
all
over
the
place
finding
bugs
in
that.
You
know
every
time
you
subtract
one
from
the
slot.
B
M
I
I
No,
I
I
would
say
maybe
we
keep
as
a
as
a
public
number.
We
keep
the
execution
layer
number,
which
is
the
current
8,
but
internally
we
have
these
slot
numbers
which
we
just
we
may
show
it
somewhere
in
explorers
or
or
something
like
that,
but
the
actual
block
numbers
would
be
just
as
as
it
is
now
in
there
will
not
gaps
any
I
mean
for
the
for
the
execution
layer.
I
G
Client
execution
payload
will
still
have
the
the
incrementing
block
number.
The
execution
environment
will
still
execute
so
that
that
separation
still
exists.
You've
still
got
slot
and
execution
block
number
that
just
flows
through
it's
just
about
avoiding
confusion,
of
which
one
you're
specifying
which
I
think
really
just
comes
down
to
which
api
you're
talking
to.
G
A
A
N
N
We
have
a
couple
of
other
things
that
you
can
see
in
the
dashboard
and
so
also
want
to
mention
that
the
press
release
for
the
standardization
of
the
metrics
has
been
merged
thanks
paris
for
that,
and
so
I
would
like
to
ask
the
different
clients
implementers
to
please
do
the
few
changes
that
are
necessary
so
that
we
have
metrics
in
standard
metrics
across
our
clients
in
a
few
couple
of
weeks,
if
possible
and
yeah.
I
think
that
would
be
all.
Thank
you.