►
From YouTube: Consensus Layer Call #88 [2022/6/2]
Description
A
Okay,
the
stream
should
be
transferred
over
if
you
are
in
the
youtube
chat.
Please
let
us
know
if
you
can
hear
us.
This
is
issue
536
on
the
pm,
repo
consensuslayer
call
88,
we'll
focus
on
the
merge,
talk
a
little
bit
about
the
reorg
that
happened
on
my
birthday
and
then
open
up.
This
is
any
other
discussion
I
want
to
handle
okay
cool,
so
merge.
We
have
a
number
of
agenda
items.
A
First
of
all,
can
somebody
give
us
an
update
on
what's
going
on
with
robston
deposit
tracking,
and
if
this
has,
if
this
is
isolated
to
specifically
what
we're
seeing
in
robson
or
if,
instead,
this
is
some
more
fundamental
issue
that
we
might
see
on
mainnet
or
might
see
during
the
merge
or
anything
like
that?
Who
has
the
update
on
this.
B
Paul
from
lighthouse
here
I
know
we
had
some
problems
on
our
end
due
to
the
really
long
block
times
up
to
like
a
minute
or
two.
I
think
so.
We
were
kind
of
voting
on
some
old
blocks,
so
not
a
threat
for
mainnet
unless
the
block
times
get
to
be
in
more
than
a
minute,
or
something
like
that.
We've
got
a
pr
up
that
solves
this.
Moves
to
a
kind
of
a
more
dynamic
approach
in
building
a
block
case,
similar
to
what
tekku
does.
A
B
C
A
Not
trashing
the
head,
it's
tracking
a
depth
and
then
we
have
to
agree
on
on
this
depth
and
the
depth
is
based
off
of
time.
Oh
time
stamps,
so
that's
going
to
be
at
least
the
the
the
grounding
of
the
reason
and
maybe
there's
some
sort
of
assumption
incorrectly
being
made
paul.
Was
there
some
sort
of
assumption
correctly
being
made.
B
B
B
A
B
Yeah,
that's
right,
I
think,
what's
worth
mentioning
as
well.
Is
that
f1
we
we
call
it
voting,
so
it
was,
is
for
better
or
worse
just
kind
of
it's
always
been
a
little
bit
a
little
bit.
Wonky
of
room
kind
of
it's
got
room
to
move
room
to
be
wrong.
So
it's
been
a
part
of
the
code
that
hasn't
received
the
same
attention
as
say
what
an
incorrect
state
route
might
receive.
B
So
yeah,
it's!
I
guess
it's
worked.
It's
it's
always
worked
well
enough
for
mainnet,
and
it's
been
the
case
that,
when
block
times
get
really
weird
and
wonky,
it's
something
that
we
can
release
a
patch
for
so
yeah.
It's
kind
of
one
of
those
flexible
parts
of
of
the
code,
but
clearly
we
could
have
done
better.
A
Okay:
okay,
okay,
I
think
there's
certainly
a
desire
to
simplify
this
mechanism
and
in
doing
so,
potentially
make
it
a
faster
mechanism.
You
know
now
that
we
are
much
more
tightly
coupled
to
the
execution
there.
I
this
isn't
a
merge
discussion,
but
I
think
it's
something
that
myself,
mikhail
and
others
want
to
spend
some
cycles
on
thinking
about,
because
it's
actually
been
when
something
goes
wrong
on
a
test
net
or
even
main
net.
You
know
it's
a
likely
culprit
should
say
assign
if
there's
some
unnecessary
complexity.
Here.
A
A
Okay,
great,
so
the
next
thing
is,
we
need
to
launch
a
sepolia
beacon
chain.
It's
generally
there's
an
issue
standing
on
the
pm
repo.
I
just
updated
this
morning
based
off
of
the
conversation
we
had
maybe
a
month
ago
about
keeping
it
the
validators
small
validators
that
small
and
generally
permissioned
and
utilizing
that.
A
I
think
we
just
need
to
agree
on
the
final
parameters
and
get
this
thing
launched
and
I
think,
there's
also
general
agreement
amongst
the
people
that
I've
spoken
with
that
launching
it
sooner
rather
than
later,
just
for
the
best,
so
that
we
are
just
generally
prepared
for
sepolio
perry
is
out.
I
think
perry
would
when
he
comes
back
and
help
us
finalize
some
configs.
A
C
A
C
Sepolia
first,
if
we,
if
we
did,
is
like
if
we
do
sepolia,
perhaps
like
when
we're
not
quite
ready
when
we
don't
have
code,
that's
like
quite
ready
for
mainnet,
but
we
do
want
to
get
another
test
that
run
in
somehow
and
and
because
it
feels
like
gordy.
What
goes
on.
Gordy
should
probably
be
like
extremely
close
to
what
goes
on
mainnet,
because
it's
like
what
most
users
will
use
and
and
test
on.
So
that's
like
the
only
reason
I
could
seem
to
do
support
before
is.
A
Yeah
I
find
that
argument
compelling
actually
just
to
be
able
to
kind
of
keep
things
moving
and
save
orly,
for
I
mean
no
matter
what
the
last
test
net
is
going
to
have
the
code
closest
to
what's
around
the
main
net.
So
I
I
buy
that
argument
and
I
we
do
do
gorly
and
main
net
shadow
forks,
which
help
us
understand
some
of
the
things
that
come
out
of
that,
obviously
something
you
mentioned
was
actually
having
a
much
more
open,
validator
set
and
having
validators
and
stakers
actually
test
this
stuff
at
scale.
A
Yeah
agreed
all
around,
I
saw
america
a
thumbs
up
as
well.
Was
this
touched
on
all
core
devs
last
week,
not
the
order.
No
okay,
we
can
do
maybe
do
a
round
of
communications
over
the
next
few
days
and
just
see
if
we
do
want
to
swap.
I
guess,
there's
nothing
been
quite
official
here,
but
nonetheless
I
think
we
should
get
this
polio
beacon
chain
out
soon,
just
so
that
it's
out
and
ready
for
our
use,
no
matter
the
order.
A
Okay,
we'll
circulate
a
suggested
date
and
configurations,
probably
in
about
a
week
when
perry
gets
back,
and
we
can
kind
of
finalize
that
okay,
something
perry
pink
me
about
this
morning,
was
robson
ttd
and
discussions
around
that
and
the
choice
of
that.
I
think
we
tim.
We
need
to
choose
that
monday.
C
C
Look
into
that
communicating
that
number
with
the
folks
who
run
validators
like
on
the
client
teams
and
and
on
the
testing
teams,
making
sure
all
those
are
upgraded
and
then
basically
publicly
communicating
the
number
so
that
in
the
worst
case
you
know
it
doesn't
affect
the
network.
If
somebody
decides
to
mine
upload
the
wickfctd.
C
We've
purposely
chosen
something
that,
like
gordy,
should
not
hit
by
next
week,
but
that
we
can
then
rent
hash
rates
to
accelerate
ourselves.
So
the
goal
would
still
be
for
it
to
be
hit.
You
know
sometime
late
next
week
but
like
given
the
current
hash
rate
on
gordy.
It's
it's.
It's
targeted
for
much
farther
than
that.
A
C
C
C
Okay,
yeah
yeah
right.
So
so
I
think
that
the
what
I
would
suggest
is
like
whenever
because
like
right
now,
there
are
client
releases
with
a
ttd
in
it
for
robsten.
Whenever
the
next
client
releases,
they
should
update
that
value
to
what
the
actual
ttp
ends
up
being,
but
I
wouldn't
like
rush
releases
to
just
have
that
value
asap,
and
we
should
just
communicate
that
people
need
to
do
an
override.
C
C
If
there's
something
that's
missing
or
wrong
for
your
client.
Please
send
me
a
message
and
I'll
make
sure
that
the
blog
posts
obviously
does
not
have
the
wrong
information.
All
the
values
in
this
posts
have
the
fake
ttd,
so
that
will
be
changed
everywhere,
but
just
generally
the
command
the
the
flag
name.
All
that
would
be
good
if
people
double
check
that
it's
accurate.
D
C
Is
is
it
like
a
significant
cost
to
keep
killed
up
to
the
main
net?
Merge
because
we
do
have
like
a
bunch
of
applications,
you've
deployed
on
it
to
test
stuff
and
they
might
not
already
have
deployments
on
roxton.
So
if
it's
not
like
a
significant
cost,
I
think
keeping
it
until
the
main
net
merge
and
deprecating
it
like
really
close
after
that
would
be
a
bit
better.
C
Is
still
up,
I
don't
even
know
that
I
think
we
can
deprecate
like
literally
today.
I
don't
think
yeah
yeah,
but
but
for
kill
itself
like
yeah,
there's
at
least
like
five
or
ten
big
applications
that
I'm
aware
that
I'm
not
sure
if
they're
still
actively
using
it
but
they've
deployed
on
it,
and
then
it
makes
it
easier
for
others
to
then
come
and
deploy
and
try
stuff.
So
I
I
would
keep
it
up
to
the
main
gun.
Merge.
C
A
F
B
A
Okay,
let's
circle
back
on
that
right
after
the
call,
I
think
we
need
to
make
sure
that
if
those
fixes
are
out,
they
should
be
agreeing
on
a
value
at
this
point
and
inducting
new
deposits.
And
if
that's
not
the
case,
that's
certainly
I
mean
tim.
The
fact
that
if,
if
people
can't
come
to
consensus
on
this
value,
then
deposits
cannot
be
added
to
the
beacon
chain,
and
so
that's
almost
certainly
what's
going
on
here,
which
is.
G
A
Okay,
so
there's
been
376
transactions
there.
We
can
clear
that
cube
pretty
quickly
once
we
begin
voting
correctly,
but
there's
that's
in
there's
also
the
follow
distance
to
contend
with
there.
I
think
that
we
can
definitely
if
we
can
patch
this
up
in
the
next
day,
then
these
validators
will
be
inducted
before
the
merge.
C
C
A
C
Has
it
yeah
sent
some
stuff,
I
think,
for
aragon
it
was
ever
for
aragon.
It
was
every
combo
for
base
two.
It
was
every
combo
except
lighthouse
and
then
for
nethermind.
There
was
one
combo
with
nimbus
that
didn't
work,
but
it's
not
clear
for
another
mind
if
it's
just
because
it
didn't
happen
yet
or
if
there
was
actually
an
issue
there.
G
I
I
H
A
You
know,
I
think
the
core
of
this
was
a
an
update
to
the
fork
choice
that
was
deemed
safe
to
roll
out
continuously,
but
then
an
additional
bug
in
the
spec
was
found
that
compounded
that
issue
casper
or
anyone
that's
been
close
to
this.
Do
you
want
to
give
us-
or
I
think,
a
lot
of
people
here
are
familiar
with
it,
but
give
anyone
listening?
Also
some
familiarity
with
what
happened
a
week
ago.
E
Sure
yeah
I
mean
so
essentially
the
initial
setup
was
that
two
blocks
virtually
arrived.
At
the
same
time,
both
blocks
accumulated
roughly
the
same
weight
and
then
essentially,
the
validators
were
roughly
split
in
half
between
running
the
proposal,
boost
fork,
choice
and
the
slightly
less
than
half
not
running
it,
and
not
the
other
way
around.
E
The
proposal
boost
and
therefore
saw
the
heavier
chain
is
leading
and
yeah
that
kind
of
concluded
the
seven
block
reorg
and,
as
danny
already
mentioned,
it's
kind
of
a
unfortunate
situation
where
validators
were
split
between
running
proposal,
boost
and
not
running.
It,
and
on
top
of
that,
this
bug
of
not
re-running
the
fog
choice,
so
if
proposers
were
re-running
the
fog
choice,
this
actually
wouldn't
have
happened.
A
A
A
A
Okay,
so
I
also
had
a
question
about
seconds
per
ethel
in
block
this.
This
is
an
estimation
to
get
to
an
approximate
depth.
This
does
not
actually
matter
like.
So,
if
you,
if
there
were
three
blocks
in
that
range,
you
would
still
you
could
still
agree
on
the
block,
even
though
the
depth
wasn't
exactly
what
you
estimated.
So
it's
not.
A
The
problem
isn't
actually
related
to
the
spec.
That
would
just
change
the
amount
of
blocks
that
you're
kind
of
digging
through
or
the
depth
that
you
get
to,
but
it
doesn't
change
the
ability
for
nodes
to
agree
at
that
depth
and
it
did
used
to
be
a
precise
block
depth,
if
I
remember
correctly,
but
was
simplified
to
the
seconds
estimation
for
simplicity
reasons,
but
I
would
have
to
pull
up
some
old
issues
to
see
exactly
why
that
was
the
case.
B
A
Well
think
about
like,
if,
if
seconds
worth,
one
block
is
15
and
you
want
to
get
to
usually
about
a
thousand
blocks
deep,
but
in
mainnet
or
in
on
the
network
you
saw
the
actual
time
between
blocks
was
30
seconds.
Then
you
would
only
get
to
500
blocks
deep,
but
that
you
can
still
come
to
agreement
with
each
other,
even
if
that
average
is
is
off.
A
A
A
G
G
What
we're
using
it
for
well
one
one
cool
use
case
that
that
has
come
up
is
that
if
you're
not
running
a
validator
you're
just
running
some
random
infrastructure
and
want
to
read
the
you
know
your
state
at
some
point,
you
don't
really
need
to
run
the
full
consensus
protocol.
So
to
that
end,
we've
actually
developed
a
little
standalone
application
that
uses
the
lifeline
protocol
to
kind
of
feed
an
execution
layer
with
what's
called
purchase,
update
and
the
blocks.
G
A
Okay
and
I
would
encourage
teams
to
send
a
person
to
all
core
devs
for
the
next
couple
of
all
core
devs,
because
I
think
we're
going
to
continue
to
be
talking
about
timing,
test,
net
launches
and
different
things
like
that
that
we,
we
generally
need
some
agreement
on
both
sides.
For
so,
if
you
can,
please
join
us
there,
and
I
will
encourage
them
to
join
us
here.