►
From YouTube: PEEPanEIP #38: Altair in Teku with Adrian Sutton
Description
Topics covered
-----------------------------
1:11 - Introduction
2:10 - Presentation - What it takes Altair to bring out in production
2:25 - What Teku is?
3:50 - The team behind Teku
4:26 - What is Altair?
6:06 - Data Structure changes
9:00 - Transition logic
10:55 - New validator duties
13:18 - New validator duty REST APIs
14:05 - Status of REST API implementation. Can end-users use these REST APIs?
17:50 - v2 REST APIs - Blocks
18:20 - Networking
20:55 - Devnets
23:13 - Next steps
25:35 - More context on Altair
28:25 - Difference between missing a sync committee signature and missing an attestation
31:49 - Sync committee signature
37:25 - What are the plans for testnets and the best place to follow along?
40:03 - Strategy behind deciding the timeline for testnets & mainnet
42:15 - Why is the beacon chain so diverted from the mainnet? Is Altair going to sync them?
49:45 - Is there a plan, timeline for Merge?
51:00 - What would be the possible changes to the project management and product management in Ethereum?
56:40 - Upgrade approach & governance in Ethereum
1:00:00 - Fork identifier on Beacon chain
Resources:
-------------------
Slides - https://docs.google.com/presentation/d/1pZhlTODTPyctgbKFsyDgXOo_wL4G7GgK_A3AP1CwcfU/edit?usp=sharing
Teku website - https://consensys.net/knowledge-base/ethereum-2/teku
Teku GitHub - https://github.com/ConsenSys/teku/
Annotated specs: https://github.com/ethereum/annotated-spec/blob/master/altair/beacon-chain.md#beacon-state-mutators
Eth2 specs: https://github.com/ethereum/eth2.0-specs/releases
Altair - Accounting reform with Alex Stokes - https://www.youtube.com/watch?v=KdhHJa2SEwY
Altair Beacon chain upgrade with Vitalik and Danny - https://youtu.be/iaAEGs1DMgQ
Consensus Layer Proposals playlist - https://www.youtube.com/playlist?list=PL4cwHXAawZxoEw29YmqJtNoFaENUUAREn
PEEPanEIP playlist - https://www.youtube.com/playlist?list=PL4cwHXAawZxqu0PKKyMzG_3BJV_xZTi1F
Survey:
---------------
Ethereum blockchain users and developers research - https://docs.google.com/forms/d/e/1FAIpQLSeugRHv93fizew0zeqXFOOnQIbjbWnVHoThLJR3f3g6gVvXhQ/viewform
Follow at Twitter
-----------------------------------------------
Adrian Sutton @ajsutton | Alita Moore @AlitaMoore85 | Pooja Ranjan @poojaranjan19
Contact Ethereum Cat Herders
---------------------------------------------------
Discord: https://discord.gg/tzYmDmF
Twitter: https://twitter.com/EthCatHerders
Medium: https://medium.com/ethereum-cat-herders
GitHub: https://github.com/ethereum-cat-herde...
Email: support@ethereumcatherders.com
Website: https://www.ethereumcatherders.com/
A
Hello
and
welcome
to
another
episode
of
evening
a
video
series
where
we
discuss
upcoming
proposals,
features
of
ingredient
blockchain.
I
am
your
host
and
today
we
are
going
to
talk
about
client
implementation
of
upgrade
watches.
This
is
an
alternative
special
episode
and
our
guest
is
adrian
sutton.
As
we
already
know,
altair
is
an
upcoming
upgrade
for
beacon
chain.
A
We
do
have
a
couple
of
episodes
recorded
with
alex
stokes,
danny
rand
and
italic
butarian
talking
about
the
features
expected
with
this
hard
book,
so
we
highly
recommend
watching
it
before
watching
this
episode
to
have
a
better
understanding
of
the
expected
features.
Links
are
provided
in
the
description
box.
Today
we
will
dive
into
the
preparation
of
upgrade
learn
about
the
team
and
testnet
preparation.
B
Thank
you
yeah.
Yes,
I'm
adrian
and
I've
been
working
with
consensus
for
about
three
years
now
I
actually
started
and
and
came
into
the
hearing
community
through
being
hired
with
consensus.
So
consensus
has
hired
a
number
of
developers
who
have
experienced
in
other
fields
and
put
them
to
work
building
clients
and
doing
other
things
like
that.
B
So
I
actually
started
developing
a
basic.
The
proof
of
work
chain
client
did
that
for
a
couple
of
years
and
then
came
over
to
help
bring
teku
from
a
research
project
and
beacon
train
from
a
research
project
to
be
ready
to
for
the
mainnet
launch,
which
was
a
really
exciting
time,
and
it's
been
lots
of
fun.
B
B
B
That
doesn't
mean
teku,
isn't
great
for
individual
stakers
and
solos
takers.
They
benefit
from
a
lot
of
these
these
features.
So,
for
example,
one
of
our
most
popular
features
is
the
ability
to
do
a
checkpoint
sync,
so
you
can
grab
a
state
from
an
existing
node
or
from
inferior
and
be
up
and
running
fully
synced
on
the
beacon
chain
in
a
minute
or
two
and
that's
actually
driven
by
needs
from
enterprise
where
they
have
kubernetes
clusters.
Nodes
might
go
up
and
down
regularly.
B
B
The
team
behind
teku
is
a
fairly
large
group
in
terms
of
everyone.
Who's
contributed,
but
in
terms
of
the
core
team
that
have
been
working
on
altair,
there's
four
of
us
meredith,
then
paul
and
I
we're
distributed
around
the
world
a
fair
bit
from
the
u.s
europe
ben
paul,
and
I
are
in
in
australia
here
and
there's
a
really
big,
supporting
cast
of
characters,
helping
us
from
consensus
as
well,
which
is
one
of
those
enterprise
benefits
that
the
tecu
has
is
that
we
actually
have
a
big
company.
B
B
This
is
the
first
time
we've
done
a
network
upgrade
on
the
beacon
chain,
there's
a
lot
of
little
details
to
it
and
a
lot
of
things
that
can
go
wrong
in
any
network
upgrade.
So
we
wanted
to
do
something
before
the
merge
or
before
sharding,
which
are
really
quite
big
upgrades
to
just
work
out
those
kinks.
So
there
are
some
really
nice
features
coming
in
in
altair,
so
the
accounting
reform
makes
a
bunch
of
things
easier.
B
What
I'm
going
to
talk
about
is
what
really
changed
the
bit
under
the
water
line
with
the
duck
madly
paddling,
because
when
you
look
at
this
list
of
things
that
we
had
to
change,
we'll
go
into
more
detail
on
each
of
them
that
bottom
one.
Some
minor
changes
from
the
spec
logic-
that's
pretty
much
everything
from
the
previous
slide.
It's
not
a
lot
of
work
to
implement
the
pure
state
transition,
changes
that
are
in
altair.
There's
some
details.
There's
some
optimizing
to
be
done.
B
B
The
biggest
part
of
the
change
in
in
altea
is
actually
something
that
has
pretty
much
never
happened
on
the
proof
of
work
chain
and
that's
that
we've
changed
some
key
data
structures.
So
if
you
look
at
the
block
data
structure
for
the
proof
of
work
chain,
those
block
headers
are
essentially
unchanged
from
genesis.
B
It's
actually
quite
hard
to
get
clients
to
to
deal
with
multiple
different
types
of
data
structures
and
transition
from
one
to
the
other.
I
think
that
the
closest
that
the
proof
of
work
chain
has
come
to
changing
data
structures
is
removing
the
state
route
from
the
receipts
and
the
clients
themselves.
Don't
really
use
that
state
brick
field
much
so
in
altair,
we've
made
a
few
fairly
decent
changes.
The
beacon
block
change
is
fairly
straightforward.
B
So,
firstly,
ssz
is
the
the
simple
serialization
format
that
is
used
for
eth2
generally
and
for
the
state
and
block
it
is
not
a
self-describing
format.
You
have
to
know
what
you're
parsing
before
you
can
can
start
passing
it.
So
there's
a
lot
of
work
in
in
clients
to
actually
track
which
version
of
the
the
ssd
schema.
Are
we
using
to
parse
any
state
we
get
or
any
block
we
get
that's
before.
We
get
to
actually
dealing
with
it
and
then
a
bunch
of
the
spec
logic
is
the
same.
B
You
don't
want
to
have
to
duplicate
and
rewrite
your
whole
state
transition
just
because
a
few
fields
change,
so
you've
got
different
object,
types
being
passed
in
and
managing
all
of
that
through
the
client
has
actually
been
quite
a
lot
of
work
all
entirely
under
the
scenes
that
you
don't
see
much,
but
it's
quite
a
lot
there
and
then
there's
a
bunch
of
new
data
structures
as
well.
In
turn
that
are
used
for
performing
the
sync
committee
duties
and
all
of
these
changes
then
flow
out
to
the
rest
apis.
B
So
when
you
request
a
block
from
the
rest,
api
we've
actually
introduced
a
new
v2
endpoint,
so
that
we
can
tell
you
whether
it's
a
phase,
zero
or
an
alte
block
and
that's
that's
a
backwards.
Incompatible
change,
particularly
for
the
beacon
state
where
you'll
get
you
know
a
different
set
of
fields
to
what
you
previously
would
have
been
expecting.
B
And
so
that's
this
transition
logic.
So
what
happens?
Is
that
when
you
process
the
first
altair
block,
there's,
essentially
these
these
four
or
five
steps?
You
need
to
go
through
you're,
starting
with
the
head
block
and
state
from
in
phase
zero,
and
you
need
to
use
the
phase
zero
spec
first
to
load.
B
That
transition
is
relatively
simple.
It
converts
the
data
structure,
mostly
just
copying,
essentially
from
one
object
to
the
other,
but
it
also
goes
back
and
migrates
the
participation
information
from
the
stored
attestations
over
to
this
new
flag
format,
so
that
you're
still
rewarded
for
for
your
attestations
from
just
before
the
merge.
If
they're
included
after
the
merge-
and
it
calculates
the
first
couple
of
sync
committees,
then
you
carry
on
and
process
any
empty
slots
after
the
ltf
fork.
B
If
you're
in
a
sync
committee,
you
create
and
publish
that
every
slot
that
you're
in
the
sync
committee,
with
a
slight
quirk
that
actually
it's
offset
by
one
slot
earlier,
so
you
actually
publish
a
sync
committee
signature.
The
slot
before
your
sync
committee
starts,
so
that
it's
available
and
ready
to
be
included
in
the
first
block
of
your
sync
committee
period.
B
So
you
know
well
in
advance
that
you
are
in
that
committee
and
you
have
duties
to
perform,
but
it
because
it's
a
different
style
to
have
a
session.
It's
not
a
single
slot.
You
wind
up
for
every
slot
in
that
kind
of
day-long
period,
you're
producing
a
signature
and
then
much
like
attestations.
You
produce
aggregate
aggregates
of
those
signatures
if
you're
scheduled
to
so
each
slot.
B
You
need
to
check
if
you're,
the
aggregator
for
the
sync
committee,
you
produce
an
aggregate
and
publish
it
out
and
then
there's
some
changes
to
how
you
create
blocks.
If
that's
so,
that's
scheduled
same
as
in
phase
zero
that
you
randomly
assigned
a
slot
to
produce
a
block,
but
you're
gathering
up
these
aggregated
sync
committee
signatures
to
include
as
a
sync
agent
in
the
block
so
a
whole
bunch
of
details
around
the
timing
there
and
the
way
those
are
scheduled
and
to
do
that
efficiently.
B
One
of
the
nice
things
about
these,
though,
is
unlike
with
attestations
and
blocks.
You
don't
worry
about
re-orgs
generally,
because
we'd
have
to
see
a
re-org
over
about
two
days
to
affect
the
sync
committee
assignments,
whereas
with
blocks,
for
example,
a
single
block
reorg
can
change
the
assignments.
If
it
happens
to
be
the
last
block
in
the
epoch.
The
next
epochs
block
scheduling
might
change,
usually
doesn't
but
in
mind.
B
B
We
need
to
be
able
to
subscribe
to
the
subnet,
so
the
gossip,
subnets
and
topics
for
publishing
the
signatures
they
they
have
broken
up
into
four
different
gossip
topics
that
signatures
are
published
on
and
you
need
to
work
out
which
of
those
subnets
you're.
Actually,
a
part
of
based
on
your
position
in
the
sync
committee
subscribe
to
them
a
random
number
of
epochs
ahead
of
the
start
of
your
committee.
So
there's
some
stability
and
find
fears
and
then
move
forward,
prescribed
yeah,
a
leader.
C
B
Yeah,
it
differs
a
little
bit
by
client,
so
for
teku
we
we've
got
all
these
done
and
ready.
We
are
still
marking
them
as
experimental,
because
if
at
the
last
minute
we
discover
something
about
them
that
might
change
that
could
break
back
with
compatibility
but
they're.
Certainly
there
and
ready
to
use,
I
think
lighthouse
is
in
in
the
same
boat,
nimbus
and
prism
are
still
working
on
their
alter,
support,
they're,
hopefully
not
far
off
but
yeah.
So
so
these
are
available.
B
You
can
take
a
tekku
release
today
and
actually
see
these
in
action.
There's
a
a
hidden
flag
to
actually
enable
altair
support.
If
you
want
to
run
your
own
test
net
or
join
one
of
the
devnets
that
I'll
talk
about
a
bit
later.
It
is
one
of
the
the
slightly
unique
things
about.
The
way
we
develop
tekku
is
that
we
don't
use
feature
branches.
We
use
a
proper,
continuous
integration
approach
and
feature
feature
flags
to
enable
and
disable
things,
so
our
altay
work
has
all
been
done
on
the
main
branch.
B
C
B
C
B
Just
kidding
yeah,
definitely
so
yeah
you
can
see
there.
You
know
quite
a
few
new
new
apis
there
in
terms
of
being
able
to
get
the
sync
committees
being
able
to
publish
them.
Publishing
contributions
to
aggregates
gets
getting
those
and
so
on,
and
then
for
for
the
blocks.
I
mentioned
the
v2
apis
so
as
we
get
closer
to
l2
and
those
apis
stabilize
people
who
are
using
the
api
should
make
sure
they
switch
from
v1
to
v2
for
retrieving
blocks
and
states
for
the
most
part
or
for
phase
zero
blocks.
B
B
In
fact,
so
this
is
an
example
of
the
v2,
so
the
key
thing
is
that
that
version
field
is
added
as
in
kind
of
the
metadata
section
outside
of
data,
and
that
will
tell
you
either
phase
zero
or
alter
which
lets
you
know,
which
fields
are
there?
So
you
can
see
the
sync
aggregate
turns
up
for
out
there
and
for
the
state
we
start
getting
inactivity,
stores
and
currency
committees
for
alta.
You
won't
then
get
the
data
station's
current
at
previous
epoch
attestations.
You
will
get
the
participation
flags.
B
The
other
really
big
area
was
around
networking.
There's
a
lot
of
work
that
happens
there.
Part
of
it
is
in
terms
of
how
we
discover
peers
that
are
on
our
chain,
so
in
discovery.
There's
an
enr
and
ethereum
node
record,
which
has
an
ether2
field,
and
it
includes
an
identifier
of
the
fork
that
you're
on
so
as
we
move
to
altair
that
fork,
identifier
needs
to
update
and
change
at
the
right
time
to
advertise.
Who
you
are.
B
You
need
to
make
sure
you're
looking
for
peers
that
are
in
the
right
state
and
particularly
as
you're
sinking,
your
train,
you
might
not
have
reached
altair.
You
know
your.
Your
head
block
is
still
back
in
the
past,
but
you
still
want
to
be
looking
for
nodes
that
aren't
out
there
and
there's
a
lot
of
small
details
around
the
way
that
works,
and
we
also
advertise
the
sync
next.
The
sync
committee
subnets
that
we're
subscribed
to
in
that
enr.
B
B
But
the
timing
and
transition
of
that
make
sure
you
connect
to
them
subscribe
to
those
gossips
and
get
that
that
whole
gossip
mesh
set
up
in
the
right
time
is
it's
quite
important
and
quite
detailed,
and
then
there's
new
versions
of
some
of
the
rpc
methods
so
similar
to
the
rest
api.
How
we
went
from
v1
to
v2
the
rpc
between
nodes
on
the
network.
B
B
So
around
you
know,
questions
on
whether
this
is
ready
or
not.
Teku
has
been
doing
up
some
semi-public
devnets.
It's
not
really
intended
for
everyone
to
jump
on
board
they're,
quite
small
they're
short-lived.
We
know
they're,
probably
going
to
fall
over
fairly
quickly,
so
kuperu
lasted
all
of
maybe
a
day
before
I
discovered
I
configured
something
wrong
with
something:
unumba
is
still
running.
B
It's
on
the
the
spec
release,
one
before
the
latest
and
and
it
actually
found
some
issues
which
led
to
this
latest
change
and
changing
the
way
that
gossip
message
ids
work.
So
so
these
have
been
really
quite
powerful
in
terms
of
identifying
issues
both
with
clients,
so
both
tecla
and
loadstar
in
particular,
have
done
quite
a
lot
of
work.
Getting
up
and
running
and
and
finding
issues
in
the
way
we've
implemented
things
and
so
on.
B
Lighthouse
has
also
managed
to
sink.
It
they've
been
a
little
more
quiet
about
what
they've
found,
but
I
assume
they've
they've
found
it
useful
as
well,
but
we've
also
found
a
number
of
issues
or
a
small
number
of
issues
with
the
way
the
spec
works
in
practice,
and
so
euronkili
is
the
current
devnet,
which
is
on
the
latest
standard.
It's
running
quite
smoothly.
B
B
So
we
can
provide
the
link
to
these.
If
you
want
to
sync
them,
I
don't
recommend
you
set
up
validators
on
them.
They'll
probably
fall
over
before
your
deposit
actually
makes
it
through
the
follow
distance
and
ready
onto
the
chain,
but
you
know
getting
a
client
up
like
you
can
grab
the
latest
teku
or
a
range
of
loads
on
lighthouse
and
sync
them.
It's
a
good
way
to
just
see
what
this
works
like.
You
can
then
play
with
those
apis
and
actually
see
real
data.
B
B
If
we
do
really
mess
this
up
and
there's
something
we
didn't
see.
I'd
expect
it
to
be
to
be
somewhat
rocky,
particularly
on
testnet
people
aren't
incentivized,
particularly
well
to
update
their
nodes
and
so
on.
So
that's
kind
of
early
july,
we'll
set
that
date.
It'll,
probably
be
more
like
late
july
august.
B
By
the
time
it
happens,
we're
gonna,
get
client
updates
out
and
everyone
to
upgrade,
and
then
sometime
after
we
see
how
well
that
goes,
we'll
start
talking
about
scheduling
it
on
main
net,
so
classic
ethereum
dates
here,
they're
subject
to
change,
they
almost
guaranteed
to
slip
backwards.
We're
going
to
focus
on
doing
this
well
and
making
sure
that
the
the
networks
are
radiant
or
the
upgrade
is
ready
and
tested
and
reliable
before
we
actually
push
it
onto
the
beacon
chain,
but
it's
coming
and
it's
coming
fairly
soon.
B
Probably
one
of
the
key
things
is
that
people
should
be
paying
a
lot
of
attention
to
releases
from
their
clients
and
just
staying
up
to
date,
because
those
when
those
fork
number
numbers
are
set,
the
slot
numbers,
then
it'll
probably
be
a
fairly
short
window,
particularly
for
the
test
stats
to
between
the
release
of
the
client
and
actually
the
fork
activating.
So
I
need
to
update
fairly
quickly.
C
Yeah,
so
one
of
my
questions
is
like
which,
by
the
way,
if
anybody
else
wants
to
ask
questions,
please
feel
free
to
interrupt
me
but,
like
I
think,
I'm
not
super
clear
on
kind
of
the
bigger
picture
of
altair
and
like
when
it's
applied
is
altair
eth2.
Is
it
the
application
of
eth2?
Like
is
altair
the
merge
or
like
that,
giving
me
some
some
more
context
on
that.
B
Yeah,
so
altair
isn't
the
merge.
So
what
we're
trying
to
move
away
from
the
term
eth2,
because
people
have
it
means
too
many
different
things
to
different
people.
So
currently
we
have
two
trains
which
used
to
be
called
e2
the
beacon
chain
and
eth1
the
proof
of
work
chain,
so
they
will
remain
separate
through
you
know,
even
after
altair
and
alto
will
apply
just
the
beacon
chain
around
the
same
kind
of
time.
B
Schedule
we're
seeing
london
roll
out
on
the
proof
of
work
check,
so
those
two
forks
needed
to
to
happen
before
we
started
talking
about
the
merge.
The
focus
after
both
of
those
goes
out
is
then
pointing
towards
the
merge.
It's
not
necessarily
guaranteed
to
be
the
next
upgrade
again.
Ethereum
dates,
they
all
change,
and
so
on,
but
yeah
alte
alta
is
basically
that
preparatory
fork
for
the
beacon
chain
to
say
yeah.
We
can
upgrade
it's
a
relatively
simple
thing
to
build
and
deploy
compared
to
something
like
the
merge.
B
Let's
get
that
right,
prove
it
out,
but
it
is,
is
a
part
of
of
what
used
to
be
called
e2
and
that
roadmap.
So
things
like
full
light.
Clients
are
bought
through
the
sync
committees
is
a
really
important
part
and
a
really
powerful
thing
that
will
will
come
in
it's
useful
to
be
able
to
track
the
beacon
chain
with
the
light
client,
it's
incredibly
powerful
to
be
able
to
track
the
merged
ethereum
with
the
light
client
and
so
by
bringing
it
in
on
the
beacon
chain.
B
Now,
once
the
merge
happens,
those
light
clients
will
actually
be
able
to
sync
all
of
the
ethereum
world
stage
and
have
that
that
same
proof,
structure
and
same
access
in
a
way
that
is
much
more
first
class
than
than
what
they
can
do.
Currently,
if
you've
ever
tried
to
use,
you
know
the
light
sync
mode
and
get
you'll
find
it's
very
hard
to
find
peers
that
are
supplying
that
information
and
so
on.
B
A
I
may
have
couple
of
questions
for
you
number
one.
First
of
all,
thank
you
for
this
wonderful
presentation.
The
first
question
is
related
to
sync
committee,
as
they
you
mentioned
in
one
of
your
slides
about
you
know
the
changes
that
are
being
brought
to
some
committee
with
this
upgrade.
So
what
is
the
difference
between
a
single
committee
missing
a
signature
and
singh
community
missing
an
attestation?
I
I
heard
these
one
of
the
independent
meeting.
B
The
sync
committee
stuff
is
actually
very
very
similar
in
in
terms
of
the
logic
but
scaled
down
a
lot,
so
it's
designed
so
that
light
clients
can
follow
it.
So
we
have
a
completely
separate
committee,
no
relation
to
ada
stations,
the
way
that
scheduling
works.
It
only
exists
in
in
outer,
so
the
sync
committee
stuff
is
first
introduced
in
altair
and
what
it
is
is
512
validators
are
assigned
to
this
long-lived.
B
Sync
committee,
for
about
a
day,
I
think
it's
256
epochs,
maybe
512
epochs
and
each
slot
in
that
period
they
produce
a
signature
which
you
know
much
like
attestations
is
saying.
This
is
what
I
think
the
head
of
the
beacon
chain.
Is.
They
don't
include
the
source
and
target
those
extra
two
fields
from
the
other
stations,
because
they're
not
contributing
to
finalization
at
all
they're
purely
letting
these
light
clients
know
in
a
way
that
is
simple
for
them
to
validate
that.
B
This
is
what
I
believe
the
head
block
to
be
so,
when
you're,
a
light,
client
and
you're
following
the
chain
and
vitalik
explained
this
much
better
than
I
ever
will
then
then
you're
you're
basically
pulling
either
those
signatures.
You
can
participate
in
gossip,
but
most
likely
the
the
aggregated
signatures
from
the
sync
aggregate
in
the
included
in
each
block
and
you're,
seeing
enough
votes
to
say
to
give
you
confidence
that
yes
you're
following
the
right
chain,
the
blocks
you
have
are
actually
validated
and
part
of
that,
and
then
from
there.
B
B
A
B
Yep
so
again,
it's
got
a
parallel
to
attestations
in
that.
If
you're
watching
your
validator
you're,
probably
worried
a
lot
about
missed
attestations
when
your
validator
didn't
perform
its
duty
for
sync
committees,
it's
every
slot
that
you're
producing
a
signature,
and
you
really
want
it
to
be
included
because
you
do
get
paid
for
it.
There
are
rewards
and
penalties
the
same
as
for
frater
stations
smaller,
but
but
still
there,
the
the
catch
is
that
you
only
get
one
chance.
So
the
sync
aggregate
is
very
simple
it.
B
When
you
produce
a
signature
for
slot
six,
it
can
only
be
included
in
the
block
at
slot
seven,
so
it
has
to
be
in
the
next
slot
and
it
has
to
agree.
If
you
get
the
head
vote
wrong,
you
just
won't
be
included
because
there
isn't
an
ability
to
include
attestations
or
any
reason
to
include
attestations
that
are
pointing
to
a
different
fork.
We're
only
talking
about
the
head
block,
not
that
source
and
target
anymore.
B
The
first
two
we
saw
very
poor
rates
of
inclusion
of
sync
committee
signatures
and
that
boiled
down
to
two
factors.
The
first
was
that
with
small
number
of
of
validators,
like
we
have
on
these
devnets,
it's
possible
that
you
actually
get
included
in
mult
the
same
validator
included
at
multiple
positions
of
the
sync
committee.
B
That's
incredibly
unlikely
on
mainnet
scale
when
you
have
100
000
validators,
but
on
with
two
thousand
dollar
data.
This
is
actually
quite
common,
and
what
you
do,
then,
is
you
produce
the
exact
same
signature,
but
you
might
be
part
of
multiple
subcommittees,
so
you
publish
it
to
two
different
gossip
topics
and
what
was
happening
was
the
the
libpeter
p
gossip
player
was
saying:
hey,
that's
the
same
message,
I'll
just
deduplicate
that
and
ignore
one
which
meant
it
didn't
get
published
to
the
right
subcommittee.
It
didn't
get
included
in
that
aggregate.
B
So
the
message
id
that
live,
pdp
uses
has
been
changed
deliberately
in
altair
to
include
that
gossip
topic,
so
messages
on
different
topics
are
always
considered
unique
and
they
flow
through.
The
second
part
of
the
problem
was
that
one
of
the
rules
in
terms
of
validating
those
signatures
is
that
the
block
they
point
to
has
to
exist.
You
have
to
have
it
at
your
node
and
know
it's
valid.
B
Otherwise
you
ignore
it.
You
ignore
that
signature
and
it
gets
dropped
from
your
node.
The
problem
is
that
attestations
and
signatures
should
be
produced
as
soon
as
you
can.
So,
if,
if
you
don't
get
a
block
for
a
slot,
you
produce
them
four
seconds
into
the
slot
one
third
of
the
way,
if
you
do
get
the
block
for
that
slot.
Well,
you
now
have
all
the
information
you
need.
B
So
we've
worked
around
that
at
the
moment
in
that
those
devnets
are
only
ever
publishing
at
the
four
second
mark
and
we're
seeing
much
much
better
rates
of
inclusion.
In
fact,
we're
seeing
almost
perfect
inclusion
but
yeah
there's
a
an
issue
with
with
the
small
size
of
the
committee
that
we'll
we'll
check
some
numbers
on
when
it's
bigger.
But
I
think
it's
it's
just
that
and
otherwise
we're
we're
seeing
them
all
come
through.
But
there's
some
ongoing
discussion.
It
wasn't
resolved
on
the
last
call
in
terms
of
how
we're
going
to
address
that.
B
We
don't
really
want
to
have
to
wait
till
four
seconds
and
it
doesn't
entirely
solve
the
problem
because
the
block
might
be
received
right
at
that
four
second
mark.
So
the
the
question
is
whether
we
delay
that
and
just
accept
it
at
four
seconds
or
leaning
towards
having
some
form
of
cache
in
place.
There's
some
discussions
that
haven't
entirely
caught
up
with
this
morning
that
that
may
give
us
a
third
option
in
terms
of
just
accepting
it
with
a
block
group.
B
A
B
A
All
right,
so
in
terms
of
devnet's,
you
mentioned
that
it
is
a
semi-public
devnet.
So
I'm
just
trying
to
understand
like
when,
when
it
was
the
genesis
of
begun
chain,
we
went
into
different
stages,
like
client
techniques,
to
the
multi-client
templates.
Then
we
managed
to
bring
it
to
like
you,
know:
public
debt,
public
test
net
and
then
to
the
main
net.
B
It's
a
similar
kind
of
process,
so
we're
essentially
at
the
client
devnet
stage,
but
because
the
beacon,
train
and
client
teams
have
matured
a
little
bit
where
we're
doing
some
interop
between
clients
at
that
stage
as
well,
but
primarily
it's
it's
a
techy
run
network.
In
fact
it
was
exclusively
toku
run.
I
sent
a
bunch
of
keys
over
to
lighthouse
and
they
got
it.
They
got
it
validating
yesterday.
So
technically,
wrongfully
is
now
a
multi-client
test
net
with
tekku
and
lighthouse,
which
is
cool
but
yeah
in
terms
of
where
people
get
involved.
B
It's
really
going
to
be
that
next
stage,
most
likely.
Actually
what
will
happen
is
that
the
first
place
people
will
really
hands
on.
We
need
you
to
be
doing
stuff
without
it
is
when
we
schedule
a
fork
for
pmonto
prada,
we're
unlikely
to
try
and
spin
up
a
third
really
big
long-lived
public
test
net.
We
just
don't
need
it
and
starting
a
test
net
on
altair
isn't
anywhere
near
as
useful
as
as
trying
to
fork
one
of
the
actual
ones
that
are
long-lived.
B
Has
this
long
history
has
real
and
very
well
distributed,
validator
nodes
and
so
on.
So
that's
that's
really
going
to
be.
The
timing
is,
is
to
to
keep
an
eye
out
for
releases
from
their
clients,
pay
attention
to
each
release.
I
suggest
get
into
the
habit
of
just
upgrading
to
each
release,
so
you
get
the
practice
of
upgrading
in
terms
of
where
to
follow
this,
the
bi-weekly
or
fortnightly,
depending
on
which
country
you're
in
a2
dev
score,
which
we
shouldn't
be
calling
e2
devs
call.
B
A
Yeah
yeah
yeah
one
last
to
follow
up
on
this.
I
know
you
mentioned
about
a
little
bit
about
timeline
like
when
to
expect
what
I'm
just
trying
to
understand
here.
Is
there
any
strategy
or
agreed
upon
duration
for
keeping
it
on
devnet
or
testing
before
deploying
on
maintenance,
or
it's
just
the
general
agreement
of
four
to
six
weeks
like
the
standard,
ethereum
practice.
B
By
and
large
we're
following
the
same
playbook
as
this
has
happened
with
the
proof
of
work
train
that
you
know
so.
For
london,
for
example,
I
forget
the
names
of
the
test
nets.
They've
had
a
few
devnets
running
and
that's
been
very
useful.
They
used
to
be
they
used
to
be
yolo
test
nets
and
and
they're,
just
relatively
small
scale
designed
for
clients
to
work
together
and
see
things
happening.
B
So
that's
coming
up
for
london
make
sure
you've
got
your
nodes,
updated,
we'll
schedule
that
fairly
soon
for
for
the
beacon
chain
for
altair,
and
then
you
roll
out
to
mainnet.
So
it's
it's
kind
of
a
tried
and
trusted
approach
to
ethereum
network
upgrades
that
we're
trying
to
follow.
It
ultimately
does
come
down
to
agreement
between
the
climate
client
teams
of
when
they're
prepared
to
ship
a
release
that
has
a
fork
epoch
set.
B
B
It's,
it
is
just
testing
it
out,
so
we're
kind
of
a
bit
more
relaxed.
We
have
people
like
like
ben
complaining
and
making
sure
we
push
it
out
and
get
it
there.
People
really
want
the
merge
and
alto
is
a
step
on
the
way
to
that,
proving
that
we
can
do
the
upgrade
so
it'll
it'll
come
when
it's
ready,
but
it'll
come
as
fast
as
it
can,
but
only
when
it's
ready.
C
B
B
And
it's
going
to
be
this
big
bang
release
one
day
we're
going
to
wake
up
and
everything's
changed,
and
and
as
you
say
when
you
do
that,
you
tend
to
get
bugs
and-
and
it's
also
very,
very
hard
to
coordinate,
and
so
there
wasn't
a
huge
amount
of
progress
being
made
in
terms
of
getting
towards
the
real
world.
There's
a
lot
of
research
and
it
was
a
productive
time
in
many
ways,
but
the
path
to
deployment
was
just
not
there.
So
what's
happened
is
people
have
realized
hey?
B
We
have
to
break
this
up
into
smaller
steps
and
we're
really
seeing
that
flow
very
well
on
the
beacon
chain
side.
Now
we're
pretty
disciplined
about
keeping
steps
small
and
we're
seeing
the
proof
of
work
chain.
Do
that
a
lot
better,
we're
generally
getting
into
the
habit
of
these
each
network
upgrade
has
a
you
know,
kind
of
flagship
feature
so
1559
for
london
and
then
there's
a
few
other
things
that
that
are
ready
at
the
same
time
and
go
out.
But
it's
that
flagship
feature
that
sets
the
timing.
B
B
So
when
we,
when
we
roll
out
an
upgrade
on
the
proof
of
work
chain,
people
like
infuria
and
coinbase
and
those
exchanges
are
really
important
in
terms
of
who's
following
the
chain,
but
in
terms
of
making
sure
the
chain
progresses,
you
need
to
talk
to
a
few
different
pools
and
you're
done.
It's
not
easy.
Hence
the
existence
of
cat
herders,
because
it's
chasing
all
those
people
up
it's
still
quite
distributed.
B
Then
only
the
staking
service
needs
to
upgrade,
but
there's
a
ton
of
home
users
home
stakers
that
all
have
to
individually
update
their
node
because
they
are
running
an
actual
node,
not
just
mining
software,
so
the
coordination
is
going
to
be
required,
is
significantly
bigger
in
the
communication
and
running
through
that,
once
is
a
really
important
thing
and
it'll
it'll
show
us
how
effective
our
communication
strategies
are.
How
well
that
process
rolls
out
and
a
lot
of
details
around
how
we
deal
with
the
fact
that
some
of
them
won't
upgrade.
B
How
does
the
network
actually
handle
the
fact
that
some
people
have
set
up
a
validator
and
paid
absolutely
no
attention
to
it,
since
they
won't
get
the
message
about
needing
to
upgrade?
They
won't
upgrade
and
they'll
be
running
off,
creating
their
own
fork
of
the
beacon
chain
very
slowly,
and
not
very
well
because
of
the
way
it
works.
You
know
lots
of
missed
slots
hundred
thousand
before
they
create
a
block
or
so
but
they'll
be
over
there
and
we'll
be
here
and
things
like
those
inactivity.
B
B
B
We
go
through
a
period
like
we
did
see
on
modasha,
where
there's
a
long
period
of
non-finalization,
where
we
leak
out
some
some
validators,
I'm
hoping
we'll
do
better
than
that,
and
it
won't
be
long,
but
I
think
we
will
see
quite
a
significant
drop
of
people
who
just
didn't
upgrade
because
they're,
it's
not
real
money,
there's
nothing
at
stake
and
in
a
proof
of
stake
network.
When
there's
nothing
at
stake,
you
get
more
problems
so
yeah
this.
B
B
That's
going
to
be
the
key
focus
of
bringing
that
in
of
bringing
that
in
that's
a
much
bigger
thing,
there's
a
lot
more
complexity
in
terms
of
the
implementation,
but
also
the
coordination
and
the
communication,
and
so
on
so
yeah
having
having
learnt
to
do
things
in
small
steps.
Alta
is
one
of
those
small
steps
that
that
doesn't
deliver
much
on
the
features
but
delivers
a
lot
on
the
testing
and
coordination
side.
C
B
Yeah
somewhat,
I
mean
I'm
slightly
hesitant.
I
think
it's
really
easy
to
get
the
impression
that
the
merge
is
happening
with
altair
and
it's
not
right.
It's
not
when
we're
not
doing
any
actual
work
on
the
merge
you
know
there
there
is.
None
of
these
features
are
merge
related,
but
yeah.
It's
it's
part
of
the
journey
towards
that
merge,
yeah.
B
C
B
B
You
know
we'll
talk
about
it
on
the
next
meeting
is
the
only
thing
that's
actually
set
there
and
I
didn't
even
set
the
date
of
the
meeting
explicitly.
That's
that's
the
level
of
confidence
we
have
in
dates
around
here
and
that's
the
level
of
confidence.
We
should
have.
That's
that's
good
and
right.
This.
C
That's
going
to
like
eventually,
you
know,
allow
us
to
say
like
well.
We
don't
know
exactly
when,
but
maybe
in
the
next
quarter,
but
we're
confident
that
we
can
get
to
get
this
done
in
the
next
quarter
or,
if
you
think
that,
maybe
that's
like
sort
of
it's
not
compatible
with
the
way
that
money
and
like
cryptocurrency
development
works.
B
So
I
think,
there's
a
couple
of
factors
there,
if
you
think
in
terms
of
a
traditional
company
where
you
get
into
trouble,
is
when
you
set
fixed
dates
for
fixed,
because
you
you
have
this
unbreakable
triangle
of
you-
know,
quality
time
and
scope,
quality
shouldn't
be
negotiable,
but
it's
the
one
that
will
always
suffer.
If
you,
if
you
set
time
and
scope,
you
will
say:
you'll
keep
quality
or
your
cuts
go.
You
won't.
You
will
cut
quality
every
time.
B
So
it
is
it's
a
terrible
idea
to
try
and
say
we
will
ship
this
on
a
certain
date
and
that's
where
most
of
the
bugs
and
problems
in
software
develop
come
from
you're,
much
better
off.
Taking
the
approach
of
saying
we're
going
to
be
agile
and
we're
going
to
deliver
in
small
steps
when
it's
ready
and
because
we're
delivering
in
small
steps,
you
can
actually
see
the
pro
the
pro
progress
we're
making
and
so
even
in
terms
of
a
classic
company.
B
I
think
that's
the
right
approach
is
we're
going
to
have
a
checklist
of
things
to
do
and
we'll
just
see
them
ticking
off,
because
they're
small
and
we're
making
constant
progress.
You
then
shouldn't
need
to
say
actually
we'll
shift
this
by
this
date,
because
what
that's
done
is
lock
you
into
the
direction
you're
taking
and
we've
seen
with
the
the
history
of
e2.
B
This
was
going
to
be
a
very
different
type
of
chain
in
in
the
original
plans
for
each
two
than
what
we've
got
today
and
what
we've
got
today
is
much
much
better
because
we
changed
our
plans
based
on
what
we
learned
as
we
were
going
and
so
small
steps.
Let
you
do
that
having
timelines
means,
you
can't
change
your
plan
because
otherwise
you'll
change
your
timeline
again
and
a
lot
of
the
criticism
for
the
e2
being
late
and
being
delayed
is
actually
because
we
changed
our
plans.
B
We
changed
the
way
we
were
going
to
deliver
and
and
for
the
better.
So
I
think
that's
really
important
as
a
starting
point,
but
I
think
the
other
aspect
is
that
we
want
to
be
a
decentralized
system.
So
when
we
talk
about,
you
know
clear
product
management,
we're
actually
talking
about
someone
who
is
saying
this
is
what
we're
doing
this
is
when
we're
doing
it.
Someone
is
the
boss.
We
don't
want
that
in
ethereum.
B
So
when,
when
you
look
at
the
way
ethereum
works
and
how
this
it's
all
this
messy
stuff
you
know
going
on,
what's
going
to
happen
is
1559
in
is
it
out?
Is
it
going
to
get
up?
Is
it
you
know
when's
it
going
to
ship
when
the
merge?
All
of
these
questions
are
actually
a
sign
that
we've
got
decentralization
and
there's
been
a
ton
of
confusion.
Anyone
who
hung
out
in
the
1559
miners
channel
that
I
spent
quite
a
lot
of
time
in
you
know
they
just
wanted
someone
to
say.
Is
it
happening?
B
Is
it
not
and
or
when
is
it
happening,
and
we
still
get
those
questions
remind
us
like
when
is
when
is
the
merge
happening?
When
do
I
forecast
my
my
return
on
investment
until
it's
like?
Well,
no
one
can
say
that
in
theory,
because
we're
decentralized
and
and
yet
that's
frustrating
and
challenging
in
so
many
ways.
But
it's
also
kind
of
the
point
right.
C
In
my
opinion,
like
I
would
say,
it
definitely
is
the
point
that
it's
a
challenge
in
a
decentralized
system,
but
I
do
believe
that
they're
I
mean
like.
I
do
believe
that
you
know
there
are
ways
to
deliver
stakeholders.
Well,
I
don't
know
but
like
I
would
assume
that
there
will
eventually
be
ways
found,
maybe
some
derivative
of
agile
or
whatever,
to
manage
it
in
a
decentralized
way
and
still
deliver
on
or
still
be
able
to
deliver.
B
Yeah-
and
I
think
that's
that's
absolutely
the
key-
is
that
we're
not
going
to
see
guarantees
and
we're
definitely
going
this
way
because
a
we're
going
to
change
our
minds
but
b,
no
one
can
agree
that
until
it's
actually
gone
out
right,
so
even
even
london
today,
the
client
teams
have
agreed
on
it.
There's
good.
B
You
know,
there's
very
strong
community
sentiment
behind
it,
I'm
fully
confident,
but
until
it
actually
goes
out
on
the
network
and
actually
all
the
nodes
upgrade
it's
not
set
in
stone
like
it
could
it
could
be
rejected
by
by
either
the
miners
by
either
by
the
exchanges
running
it.
It's
a
decentralized
system.
Everyone
has
to
agree
to
this
upgrade
to
going
forward.
C
C
I'm
seeing
like
kind
of
eth2
is
really
exciting
in
a
lot
of
ways.
Both
I
mean
you
know
we're
switching
over
to
proof
of
stake,
and
then
you
know
a
lot
of
other
things
or
whatever,
but
also
it
feels
like.
This
is
a
new
like
what
you're
describing
is
a
new
way
of
approaching
sort
of
the
project
management
than
what
we
do
right
now,
which
is
you
know,
scheduled
forks
that
occur
every
so
often
with
a
bunch
of
different
changes
or
as
many
as
it
can
get
crammed
in
right.
B
Yeah,
I
think
yes,
and
no,
I
think
some
of
this
has
been
you
know.
There's
there's
certainly
been
people
pushing
for
this
on
the
proof
of
work
chain
as
well,
that
eips
should
just
ship
when
they're
ready
and
not
necessarily
bundle
them
up
into
releases.
We've
seen
big
problems
with
with
upgrades
being
delayed
because
we're
trying
to
get
a
lot
of
vips
that
all
had
to
be
ready
and
when
one
got
delayed,
the
whole
upgrade
got
delayed
instead
of
that
one
just
not
being
in
it.
B
So
more
and
more
we're
seeing
you
know
that
that
flagship
feature.
That's
what
sets
the
date.
Whatever
else
is
ready
happens
to
go
with
it
and
that's
that's
kind
of
an
example
of
doing
small
steps
and
it's
kind
of
the
approach
we're
trying
to
take
on
on
the
the
be
constrained
side
as
well.
I
think
there
is.
There
is
kind
of
a
merge
of
governance
that
needs
to
happen
yet
in
terms
of
the
way
the
two
chains
work.
B
So
we
need
to
do
better
at
including
them.
So
you
know
we
have
the
eip
process
on
the
proof,
work
chain
and
different
ways
that
communicates
there's
still
a
lot
of
mess.
You
know
so
a
lot
of
people
don't
follow
it
very
well
and
they're
surprised
that
something
you
know
change
is
coming
we'll
we'll
have
to
work
out
how
that
fits
in
with
what
what
at
the
moment
is,
is
very
client
driven
on
the
beacon
chain
side.
B
The
client
teams
are
coming
to
agreeing
on
things
we're
starting
to
see
that
already,
though,
in
more
and
more
communication
between
people,
so
altair
has
a
change
that
was
put
into
the
rewards
for
sync
committees
because
of
the
work
a
community
member
did
photos
said.
Actually
this
is
a
problem:
they're,
not
a
client
dev.
They
hadn't
been
on
a
call
before,
but
we
got
them
on
to
the
developers
call
to
have
their
say
why
this
is
a
problem.
It
was
one
of
our
biggest
arguments
on
the
call.
It
was
great.
B
No,
it's
a
really
productive
discussion
in
terms
of
the
back
and
forth
there,
and
so
we'll
see
that
come
through
and
we
will
likely
have
to
to
better
track
separate
changes
and
we
do
to
some
degree
their
separate
pr's
against
the
spec
at
separate
issues.
But
you
will
see
more
and
more.
These
individual
changes
having
a
life
of
their
own
and
then
finding
their
way
into
an
upgrade
kind
of
when
they're
ready,
just
the
same
as
as
it
happens,
on
the
proof
of
work
chain
now,
you'll
you'll
see
them
coming
together.
B
A
Right,
thank
you.
Thank
you.
So
much
these
are
all
good
information.
I
know
we
have
hit
an
hour.
I
just
had
one
final
question
for
you.
I
mean
I
was
just
going
through
the
slides
and
it
came
to
my
mind.
So
I
was
trying
to
get
some
clarity
on
that.
You
briefly
mentioned
about
discovering
notes
and
the
fork
identifying
features.
So
I
I
there
was
this
proposal
in
the
ethereum
one
dot
co
chain
that
is
eip
two
one,
two
four
four
identifier
on
chain
is
it
the?
A
B
Very
similar
concept,
totally
different
mechanics,
but
very
similar
concept
of
a
short
string
that
tells
you
you
know.
Is
this
node
on
the
same
chain
as
me?
Do
we
expect
the
same
things
in
in
the
case
of
the
beacon
chain?
It's
slightly
stricter,
it's
not
just
which
four
conversions
and
which
which
block
slot
or
slots
they're
at.
But
it's
also
the
the
genesis
validators
route,
which
is
which
is
really
cool.
B
So
I
can
spin
up
two
networks
that
all
fork
at
the
exact
same
point
and
they're
quite
unique,
because
they
have
different
genesis,
validators
and
that
saves.
So
it's
quite
a
lot
of
grief
and
it's
used
in
right
through
the
spec
to
to
avoid
different
chains
clashing
with
each
other
and
getting
slashed
and
different
things,
as
well
as
that
fork.
Identifier,
yeah
yeah,
incredibly
similar
in
terms
of
the
idea.
A
Sounds
good
yeah.
This
is
like
a
lot
of
interesting
conversation
and
we
are
seeing
how
both
the
chains
are
working
in
parallel
and
we
hope
to
have
you
know
the
merge
getting
closer
on
behalf
of
like
communities.
I
would
like
to
thank
you
for
taking
our
time
and
talking
about
the
secrets
of
this
development
camp.
A
A
All
these
resources
and
the
slides
of
the
presentation
that
were
discussed
in
the
meeting
today,
along
with
the
guest
twitter
handle,
will
be
provided
in
the
description
box.
Do
follow
them
to
learn
about
the
development
update
in
deku
and
we
can
cheat
next
week.
We
will
have
another
special
guest
to
talk
about
a
difficulty
bomb
in
london,
upgrade
that
is
vip
3554,
but
james
hancock,
so
stay
tuned.
Keep
watching
keep
sharing
your
love
with
the
medium
catalyst.
Talk
to
you
in
the
next
episode
have
a
good.