►
From YouTube: Eth2.0 Call #66 [2021/6/17]
Description
A
A
Here's
the
agenda,
nothing
crazy,
client
updates,
with
a
focus
on
altair.
We
will
discuss
the
point
brought
up
by
adrian
today
on
some
of
the
subtleties
on
gossiping
sync
signatures:
we'll
talk
about
altair
planning.
Thank
you
for
perry
for
joining
to
help
us
discuss
and
coordinate
that
and
then
general
discussion.
The
merge
call
was
right
before
so.
A
B
Sure
so,
we've
updated
to
the
alpha
7
release
with
the
new
gossip
message,
id
changes
and
the
new
rewards
for
sync
committees.
That's
all
up
and
running.
We've
kicked
off
euronpili
testnet
with
that.
So
the
details
are
in
the
e2
test
nets:
repo
prefixes
to
the
node
health
api,
to
make
it
work
a
bit
better
with
kubernetes
in
particular.
For
us
we
now
say
we're
syncing
on
that
api
right
after
startup
until
we
found
peers.
B
C
C
I
think
we're
on
track
to
start
a
local
interruption
test
net
to
test
the
for
transition
by
end
of
this
week
or
early
next
week,
and
if
that
goes
well,
we
will
jump
into
the
multi-client
test
net
with
you
guys
as
well,
and
on
the
maintenance
front,
we
are
planning
to
release
our
e2
api
support
by
nets
release
so
that's
very
exciting
and
other
than
that.
Just
bug
fixes
and
then
yep,
that's
it.
Thank
you.
E
As
of
right
now
it
looks
pretty
good
locally.
We
need
to
upgrade
this
alpha
seven
and
see
see
what
it
looks
like
other
than
that
I've
been
doing
some
other
optimizations
and
things
we
we're
going
to
delete
our
pending
at
the
station
cache,
because
we've
found
out
it's
not
very
dos-resistant
and
looking
for
feedback
or
ideas
how
to
actually
implement
something
like
that.
E
F
Hello,
everyone
paul
here
so
with
regard
to
altair,
we've
got
alpha
7
merged
into
our
altair
branch.
It's
working
well
passing
tests
we're
following
euronpili.
We
seem
to
be
getting
sync
committee
messages.
We
had
a
couple
of
issues
with
the
new
configs,
but
we
sorted
those
out
and
kind
of
yeah.
It
seems
to
be
working
out,
we're
looking
into
it
to
try
and
find
some
bugs
and
weirdness,
which
I'm
sure
we'll
find
we're.
Also
without
today
we're
patching
an
issue
with
our
bc.
F
We
had
some
some
problems
about
signing
just
around
the
fork
boundary,
so
we're
going
to
fix
that
we're
still
finishing
some
caching
stuff
and
then
we'll
be
working
on
merging
our
alter
branch
into
our
primary
branch.
At
some
point
out
of
altair
now
last
week
we
released
version
1.4.0
and
it
went
quite
well,
which
was
nice.
F
We
dropped
our
memory
from
like
six
gig
to
like
1.5
gig
dropped,
calls
to
f1
nodes
by
about
80,
and
the
users
seem
very
happy
so,
which
makes
us
happy
and
moving
forward
we're
going
to
be
pushing
forward
with
altair
and
hopefully
cutting
a
version.
1.5.0
release
maybe
end
of
this
month,
starting
next
month,
we
should
have
some
cpu
savings
and
a
bunch
of
other
features.
A
B
A
A
I
think
that
most
of
you
have
met
peritosh
perry,
who
is
at
the
ef,
who
does
primarily
e2
devops
related
tasks,
so
you've
probably
run
into
them
with
test
nets
and
other
things
perry's
going
to
be
joining
our
calls
here
and
and
getting
his
hands
dirty
with
various
test
net
things
so
helping
set
dates,
helping
pick
and
host
configs
and
and
that
kind
of
stuff,
and
then
maybe
working
through
problems
if
they
arise
like
hitting
epoch,
10
and
forgetting
and
then
changing
its
ebock
20.
perry.
F
A
C
A
It
very
well.
We
might
get
to
the
first
be
comfortable
setting
a
test
net
fork,
but
then
wanting
to
regroup
on
the
15th,
which
would
be
another
call
before
we
actually
maybe
we'll.
The
intention
would
be
to
fork
one
of
those
then
to
get
to
the
15th
and
then
set
fork
targets
for
if
things
had
gone
well,
forked
targets
for
the
other
test,
not
in
for
maine.
At
that
point,
I
think
definitely
in
the
august
early
mid-august
horizon
for
an
earliest
main
network.
A
B
Moving
yeah,
I
think
that
sounds
about
right.
I
think
the
the
key
thing
we
need
to
get
onto
now
in
terms
of
talking
test
nets
is
getting
users
used
to
the
fact
that
it's
coming
and
coming
fairly
soon,
and
they
will
have
relatively
short
notice
to
upgrade
right,
because
otherwise
it's
going
to
go
very
badly
when
the
change
splits.
F
A
It's
not
that
this
is
correct,
but
it's
certainly
not
done
on
a
per
fork
basis
for
most
eth1
mainnet
clients,
and
that's
not
saying
again
that
it
is
correct,
but
they
rely
heavily
on
testing
and
and
test
nets
and
assume
that
their
architecture
is
generally
correct
and
that
they
and
those
processes
are
the
things
that
are
going
to
best
find
consensus
bugs,
which
is
probably
true
from
a
two
week.
Audit
perspective.
But
extra
eyes
is
never
a
bad
thing.
A
A
A
A
B
Yeah,
so
in
the
earlier
test
nets
we
found
that
we
were
losing
gossip
messages.
Basically,
the
inclusion
rate
for
sync
committee
signatures
has
been
really
low
with
the
message
id
changes
that
jumped
up
to
about
70
inclusion
rate,
but
we
were
still
missing
a
bunch
and
it
turned
out
that
it's
because
the
network
was
functioning
really
well,
so
we
were
producing
a
block
every
slot
and
then
immediately
producing
a
sync
signature
and
for
both
nodes.
B
Actually
in
the
network,
they
were
managing
to
process
the
sync
signature
before
they
actually
imported
the
block,
and
so
they
wound
up
ignoring
most
of
the
signatures
and
it's
just
the
same
race
condition.
We've
seen
with
attestations.
If
you
publish
them,
when
you
first
receive
a
block
and
other
nodes,
don't
have
any
any
caching
say
for
later
type
behavior.
B
You
get
this
race
condition
between
the
block
and
the
the
sync
committee
signature
or
the
app
station
actually
being
ready,
causing
causing
you
to
drop.
Some
I've
run
an
experiment
this
evening
with
delaying
producing
sync
committee,
signatures
to
the
four
second
mark
in
the
slot
and
we're
not
getting
100
participation
yet,
but
we're
missing
entire
subnets
at
a
time.
So
I
think,
what's
happening.
B
Is
that
we're
randomly
not
getting
an
aggregator
and
to
do
one
more
log
message
to
prove
that,
but
I'm
pretty
sure
that
we're
actually
getting
perfect
inclusion
rate
of
signatures
now
and
we
just
sometimes
don't
aggregate
so
essentially
that
that
delay
solves
the
problem
and
we
now
just
need
to
have
a
choice
between
whether
we
I
think
there
are
three
proposals
on
the
table.
One
is
just
don't
publish
signatures
early
when
you
get
a
block,
always
wait
for
the
four
second
mark.
B
A
Of
them
are
probably
my
gut
would
be
to
go
with
the
second
and
introduce
a
short-lived
cache
so
that
you
can
kind
of
have
the
dispersal
of
attestation
messages
not
all
being
blasted
exactly
the
same
time
and
reuse
the
mechanism
that
protects
attestations
from
from
having
the
same
issue.
Obviously,
the
cash,
I
think,
should
be
much
more
short-lived
on
the
order
of
slot,
rather
than
I
think,
on
the
order
of
an
epoch,
and
we
get
to
ideally
reuse
kind
of
the
the
similar
logic
from
that
structure.
B
Yeah,
I
mean
that's
the
way
I
lean
as
well,
partly
because
I
already
have
the
attestation
case,
so
I
can
plug
it
in
relatively
easily
for
any
client
who
doesn't
do
that.
Yet
that's
obviously
more
work.
So
that's
a
consideration
and
it
just
feels
it's
a
deterministic
deterministic
solution.
You
are
never
going
to
reject
a
signature
because
you
don't
have
the
block
yet,
but
assuming
you
will
get
pretty
good,
it.
F
F
B
F
Yeah,
I'm
not
saying
the
case
is
like
definitely
a
bad
idea.
I
think
the
delay
is
also
a
good
idea,
because
I
I
I
mean
I
get
somewhere
else,
but
if,
if
we
know
that
we're
going
to
have
to
cache
these
things,
then
why
make
every
node
on
the
network
k-shirt
rather
than
just
the
sender,
hold
it
for
a
little
bit
more.
F
That's
that's
one
argument,
and
then
another
argument
is
that
if
we
just
have
some
delay,
then
you
can
get
by
without
a
cache
and
if
the
cache
isn't
a
perfect
case
like
in
this
case,
we
can't
always
verify
the
signatures
going
into
it.
Then
there's,
like
you
know
the
case,
isn't
a
perfect
deterministic
solution
and
we
already
have
this
problem
with
attestations,
like
I
think
loads
dimension
to
the
start
of
it.
How
do
you
make
the
attestation
case?
Boss
resistant?
You
can't
same
with
this
one
you
can't.
A
A
F
I
guess
I
mean
it's
probably
not
thinking
that
it's
only
512,
it
probably
doesn't
earn
you
a
whole
lot,
but
just
I
guess,
looking
from
like
a
broader
network
perspective,
you
know
if
you're
gonna
you've
got
a
message
right,
do
you
does
the
send
and-
and
you
know
that
that
every
the
receivers
all
need
like
half
a
second
before
they
can
process
it
to
you.
Do
you
hold
it
on
the
sender
side,
or
does
every
receiver
hold
it
until
they
get
it
yeah,
I'm
not
sure
that
that's
the
strongest
start.
A
F
E
F
B
I
A
A
B
I
think
one
of
the
things
the
bits
of
data
we're
missing
in
this
is
that
we
don't
have
a
decent
sized
network
that
we're
seeing
how
this
actually
behaves
in
the
real
world.
So
I've
got
two
nodes
that
are,
you
know
right
next
to
each
other
in
aws,
it's
not
really
surprising,
they're
getting
the
block
all
at
the
same
time.
It's
all
happening
very
fast,
whereas
even
on
piermont
and
prada
we're
seeing
a
much
bigger
distribution
of
when
blocks
arrive,
and
you
know
take
your
publishers
at
a
station
straight
away.
Lighthouse
currently
drops
them.
B
A
So,
if
possible,
I'd
like
to
solve
it
with
one
of
the
two
or
one
of
the
suggestions
that
just
touches
the
p2p,
rather
than
adding
some
sort
of
induced
delay
on
the
on
the
state
transition
side.
If
we
want
to
gather
more
data,
that's
I
don't
think
it's
critical
that
we
can
form
on
the
solution
immediately
right
now,
but
we
should
probably
pick
something
in
the
next
five
days.
F
A
There's
multiple
reasons
there
one
would
be
there
is
this:
you
do
want
ad
decisions
well
propagated,
so
that
aggregation
can
happen
at
that
eight
second
mark,
and
so,
if
you
have
the
information
that
you
need
to
send
your
message,
the
idea
is
that
it's
an
optimization
to
send
your
message
when
it's
available
like
when
the
correctness
is
available,
and
then
that
also
is
so
that
you
can
potentially
get
aggregated
at
a
higher
success
rate.
But
then
that
is
also
a
does
help
stagger.
F
A
But
even
then,
even
if
you're
not
finalizing
for
an
entire
day,
the
assuming
that
there
was
actually
two
forks
that
are
deep
of
an
entire
day
and
that
those
networks
are
actually
those
partitions,
the
network
are
actually
communicating
and
not
resolving.
That
fork
is
like
a
more
extremist
issue
in
and
of
itself.
B
B
B
A
Otherwise,
if
we
needed
to
get
some
better
data
on
larger
networks,
then
we
can
take
it
there.
Adrian
you
mentioned
something
as
an
aside
that
was
interesting,
that
you
were
not
getting
aggregators
you
weren't,
always
getting
aggregators
on
different
sections
of
the.
I
think
many
subnets,
I
believe
the
number
of
aggregators
was
the
target
number
aggregator,
which
is
actually
reduced,
and
that
might
be
an
error,
not
an
error,
but
it
might
not
be
a
good
thing.
So
do
you
have
any
other
data
on
that
or
should
we?
B
I
think
the
key
thing
is
to
try
it
with
a
bigger
set
of
validators.
I've
only
got
two
thousand
four
hundred,
so
I'm
seeing
duplicates
in
the
same,
oh
okay,
which
we're
not
expecting,
and
that
makes
it
less
likely
if
you
get
an
aggregator
okay
that
makes
sense
but
yeah,
it
is
definitely
worth
reviewing
those
numbers.
Yeah.
A
A
K
K
Currently,
we
split
shared
proposers
up,
or
we
split
validators
up
in
charge,
committees
and
then
out
of
these
committees.
We
select
the
proposers
to
keep
the
proposers
bare
shard
separate
for
a
time
window
of
about
a
day,
and
so
this
helps
the
network
player,
but
within
the
spec
there's
not
really
much
to
it.
K
So
we
may
even
end
up
with
a
model
where
the
proposers
can
select.
Data
can
grab
data.
They
don't
have
to
learn
all
the
layer
tools,
they
don't
have
to
specialize
as
much
and
then
it's
the
builder
that,
after
paying
the
fee,
is
then
incentivized
to
make
the
data
available
by
publishing
it
on
the
chart
topic
and
so
we're
looking
into
this
changing
incentives.
How
that
could
work.
K
And
then
it's
basically
the
data
trans,
the
data
transaction
that
first
offers
the
data
and
then
later
the
builder
publishes
the
data.
So
we
shift
this
availability
problem
towards
the
builder,
and
so
this
is
good
for
privacy,
since
we
don't
have
to
so
it's
like
if
we
have
this
very
critical
part
of
publishing
the
data
like-
and
this
is
a
larger
piece
of
data
on
the
charts
if
he
moved
it
away
from
the
federator
from
the
consensus
identity-
and
I
mean
it
can
still
be
the
same
person.
J
K
H
K
Builder
can
still
combine
different
tabs;
they
can
still
combine
data
and
fit
it
together
in
one
block
and
then
we're
thinking
of
like
a
standard
outside
of
the
protocol,
but
something
that
deps
would
use.
Think
of
it
like
the
erc20,
like
which
kind
of
layer
this
lives
on,
and
we
basically
just
need
users
of
shard
data
to
recognize
which
part
of
the
chart
blob
is
being
used
for
which
protocol
or
for
which
application,
and
so
we
need
some
kind
of
small
header
to
say
where
to
find
data
of
specific
tabs.
K
J
K
Right,
so
it
is
similar
to
the
mainnet
separation
in
a
way
that
we
do
have.
Builders
like
this
data
still
has
meaning
it's
just
that
the
base
parts
called
layer,
one
doesn't
execute
the
data,
but
the
builders
will
still
want
to
execute
their
rollup
data
and
sequence
transactions,
whatever
they
want
to
do,
and
this
is
separate.
It's
a
separate
process
from
the
shared
proposal
rule
which
just
needs
to
select
data,
and
then
we
shift
this
incentive
from
of
the
availability
towards
the
builder.
K
L
Yes,
just
a
quick
comment:
the
the
word
that
I
showed
a
couple
of
months
ago
about
the
resource,
consumption
of
the
different
clients
will
be
published
at
the
blockchain
research
conference
in
paris
in
september,
and
there
will
be
also
a
poster
about
the
network
crawlers
that
we
have
been
working
on
and
talking
about
the
new
crawler.
We
developed
a
new
version
of
the
crawler
that
can
run
24,
7
and
gather
data
continuously
and
charging
a
dashboard.
A
Today,
okay,
we
will
aim
to
get
this
p2p
sync
committee
issue
resolved
in
the
coming
days,
and
we
also
are
continuing
to
increase
test
coverage
for
altair,
so
we
will
expect
a
new,
very
iterative
release
next
week
with
additional
tests.
Then
thank
you
really
appreciate
all
the
hard
work
and
excited
to
see
altair
moving
talk
soon,
bye.