►
From YouTube: Eth2.0 Call #70 [2021/8/12]
Description
A
A
A
A
A
Okay,
I
think
the
most
topical
thing-
and
we
can
talk
about
immediately-
is
this
altar
devnet
iii.
This
was
led
by
perry
and
has
a
different
client
ratio
than
our
even
split
on
the
past
few,
to
attempt
to
represent
at
least
what
we
know
of
mainnet
today,
something
like
70
prism
and
last
I
saw
there
were
a
few
things
being
worked
out
still
this
morning.
Is
there
an
update
on
that?
A
I
guess
mainly
because
we're
going
to
talk
about
pyrmont,
which
is
in
a
week-
and
I
just
want
to
make
sure
that
we
are
still
good
to
go.
I
imagine
anything
that
we
can
anything
that
has
opened
up
on
that.
We
should
be
able
to
settle
in
the
next
few
days,
so
my
expectation
is
paramount,
so
good,
but
where
are
we
at.
B
I
think
lodestar
is
doing
a
lot
better
now
they
said
they
were
overloaded
and
they
increased
their
their
machine
size.
I
guess,
and
besides
that
there
was
an
invalid
signature
that
was
noticed,
and
here
some
peer
scoring
related
things
for
the
lighthouse,
but
I
think
I
let
the
lighthouse
team
take
it
on
from
that.
D
A
D
B
Another
thing
that
I
don't
think
I've
mentioned
otherwise
is:
there
seems
to
be
a
load
stop
here
that
both
lighthouse
as
well
as
prism,
have
banned
for
for
invalid.
What
does
it
say?
Invalid
sequence?
Number,
I'm
not
particularly
sure
why
that's
happening,
but
I
can
share
the
logs
and
we
can
take
it
from
that.
D
A
Yeah,
it
is
an
indoor
condition,
but
yeah
it
might
make
sense
to
lighten
that
up
at
least
once
you
figure
it
out.
So
I
moved
the
client
updates
to
after
this.
So
we
can
just
talk
about
altair
in
unity
with
this,
so
we
do
have
a
pyramid
date
set
up
adrian.
Thank
you
very
much
for
getting
that
config
ready
and
porting
it
to
the
new
format.
A
Okay,
so
we
will
obviously
figure
out,
what's
going
on
attempt
to
get
some
patches
out
before
then,
and
if
we
find
related
or
different
issues,
hey
doc,
red
you
are
typing
lab,
I'm
muting
you!
If
we
find
continued
edition
children
pyramid,
it
will
continue
service
purpose,
which
is
to
find
issues.
So,
let's
keep
chatting
as
as
we
work
through
the
issues
on
the
current
devnet
and
take
it
from
there.
A
A
Terence,
had
found
a
bug
in
their
state
transition
code
that
was
iterating
on
like
the
full
validator
list,
rather
than
the
active
validator
list,
and
this
only
serviced
a
bug
in
the
event
of
leak,
scores
being
non-zero
there
being
validators
that
were
not
active,
so
exited
or
not
yet
active
and
a
leak
going
on.
So
we
did
get
that
case
covered
in
the
dev
branch
and
are
working
on
enhancing
a
bit
more
coverage
and
then
we'll
we'll
get
a
release
out
there.
So
keep
your
eyes
peeled
for
that
and.
A
That's
primarily
what
I
have
for
altair.
We
could
discuss
theoretical
dates
for
pratter
and
or
mainnet,
but
my
intuition
is
given
some
issues
seen
on
the
devnet
and
with
the
pyrmont
launch
in
a
week
that
we
were
better
suited
sorting
through
these
issues
before
we
try
to
put
a
date
on
anything
else,.
A
G
G
We
are
actively
working
on
lowering
our
memory
usage
and
we
have
found
three
strong
strategies
with
the
help
of
blotto2.
So
hopefully
we
can
get
that
merged
soon
and
we
should
release
by
monday
a
lifeline
article
with
a
working
demo.
That
would
be
connected
to
alternate
three
and
that's
it.
Thank
you.
F
Hey
guys
sean
here
so
for
the
last
two
weeks,
we've
been
mostly
focusing
on
bringing
down
our
changes
from
our
hot
fog
branch
to
our
developed
branch
in
the
process,
we've
been
carefully
reviewing
the
code
we
have
implemented
for
altair
and
in
the
process
we
found
a
bug
in
our
state
transition
function,
as
mentioned
earlier,
so
it's
not
covered
by
inspectors.
So
this
has
been
valuable
in
finding
different
edge
cases.
F
So
we
are
happy
to
have
that
sorted
out
along
with
that,
we
have
actually
finally
implemented
all
the
official
api
endpoints
in
our
developer
branch,
so
this
has
been
in
the
world
for
a
long
time.
So
we're
happy
to
have
that
done
and
now
we're
in
the
process
of
implementing
our
v2
endpoints
for
altair.
D
Hey
there
paul
here
not
a
whole
lot
to
report.
This
time
we
did
publish
a
pre-release
which
is
1.5.0
rc
0..
So
this
is
the
release
that
we're
going
to
ask
users
to
use
for
the
pmo
fork
we
might
or
may
not
make
another
release
in
the
meantime,
we
just
want
to
try
and
get
everyone
ready
for
it
early.
We
pro,
we
probably
won't
publish
a
full
1.5.0
before
pm
on
we're
just
trying
to
prioritize
those
stable
releases
for
mainnet.
D
We
don't
really
want
to
let
pimon
dictate
the
pace
in
which
we
do
things
for
mainnet,
where
now
that
we've
got
kind
of
staying
to
get
that
release
out
the
door
which
includes
doppelganger
and
a
bunch
of
other
cool
features,
it
also
means
all
of
our
lts
stuff
is
now
merged
out
of
it's.
It's
not
no
longer
living
in
separate
branches,
and
it
lives
in
in
at
least
unstable
for
now,
which
is
pretty
cool.
So
now
we're
progressing
with
our
weak
subjectivities.
D
A
D
Yeah
thanks
we've
had
a
chat.
We're
trying
to
one
of
the
ways
you
can
go
is
like
by
you
know,
buying
a
giant
box
and
splitting
it
up,
but
we're
trying
to
keep
it
in
separate
nodes
all
around
different
ips
and
stuff.
Like
that
yeah
we
see
in
test
nets,
people
lots
of
people
running
behind
the
same
ip
and
it
makes
things
a
little
bit
weird
for
us
not
represented
in
normal
conditions.
Gotcha.
H
A
I
Hey
this
is
adrian:
we've
got
our
21.8.0
release
that
came
out
today
and
that
has
altea
air
support,
finalized
and
ready
to
go.
It
is
scheduled
to
activate
on
piermont
at
the
right
point,
so
really
important
that
everyone
on
piermont
upgrades
to
that
a
bunch
of
stuff
happening
in
the
background
in
terms
of
research
and
other
fixes,
there's
been
some
docker
upgrades
and
various
little
details
to
make
things
easier
to
manage
in
bigger
environments.
B
I
J
Hi,
I'm
here
sold
updates
for
the
past
two
weeks.
We
now
have
multi
architecture,
docker
images,
also
we
released
v
1.4.2,
which
is
an
update
just
before
london,
because
we
had
a
lot
of
people
running
client,
older
than
march
2021,
and
they
had
issue
when
jump
once
jumping
from
1.0.13,
I
think
to
our
latest
client
version.
So
that
was
an
update
just
for
votes.
J
A
A
I
suggest
that
we
use
that.
I
mean
we
don't
need
those
numbers.
We
don't
need
a
thousand
validated
deposits,
but
use
that
as
a
starting
point
on
some
of
the
conditions
we
want
to
see
and
make
sure
on
that
first
week
of
pyrmont
to
kind
of
hammer
it
with
a
bunch
of
different
things
to
make
sure
that
we
see
some
of
the
interesting
edge
cases.
I
guess
additionally,
we
might,
because
we
control
a
significant
number
of
the
nodes
on
pyramid.
A
It
would
likely
make
sense
to
turn
a
bunch
of
them
off
to
test
a
stretch
of
non-finality
on
a
test
net
that
is
planned
on
being
moonlit
and
probably
is
not
the
place
where
users
are
expecting
a
super
high
quality
of
service.
So
I
think
that
would
be
a
good
place
to
do
some
stuff.
So
maybe
over
the
next
couple
of
days
we
can
come
up
with
a
a
plan
on
you
know.
If
and
when
pyrmont
goes
well
at
the
start,
then
we
can
kind
of
hammer
it
in
finality
case
and
hammer
it.
A
K
K
This
is
based
on
like
earlier
posts
from
vitalik
and
others
about
separating
mfv
and
trying
to
create
this
market
for
data,
and
this
should
also
help,
for
example,
ease
the
burden
on
federators
to
not
specialize
in
every
single
layer
too,
but
rather
move
this
burden
to
the
builders,
and
it
simplifies
different
parts
of
the
specification
and
we
just
merged
it
after
a
month
of
development,
but
it's
not
timeless
at
all.
Yet.
So,
if
you
want
to
take
a
look,
please
do
and
we'll
keep
polishing
these
yarnings
back
in
the
next
few
weeks.
A
Right,
additionally,
and
also
one
of
the
features
that
I'm
really
happy
about
is
puts
the
incentives
on
the
cr,
the
making
of
that
data
available
directly
on
the
builder's
standpoint,
who
can
specialize
in
particular,
subnets
or
shards
or
different
distribution
mechanisms
that
puts
a
lot
less
complexity
on
the
core
kind
of
validator
network
and
spec
and
requirements
cool
check
it
out.
I
shared
that
that's
24.86.
A
Okay,
moving
on
to
the
merge,
I
believe
the
merge
was
rebased
both
to
altair
and
london
recently,
so
it
is
getting
primed
for
kind
of
the
next
wave
of
r
d,
and
there
are
a
couple
of
issues
that
we
wanted
to
discuss
in
the
rebase
to
london.
The
base
fee
there
were
some
calculations
put
in
there
on
the
base
g
and
the
base
view
is
represented
as
a
un-64..
A
This
is
unsafe
in
some
scenarios
for
overflows.
Thank
you
proto
for
pointing
that
out.
So
there's
probably
two
alternatives:
the
pr
that
mikkeil
put
up
2548.
that
moves
to
un256
and
has
some
uni-256
calculations.
This
is
because
some
of
the
base
fee
validations
were
put
into
the
beacon
chain,
spec
so
doing
the
calculation
to
make
sure
the
base
view
is
correct.
A
The
other
alternative
which
I
would
lean
slightly
towards
is
to
make
this.
You
know
bytes
32
value
that
the
beacon
chain
doesn't
really
care
about
and
that
the
validations
in
the
execution
layer
continue
to
happen
as
they're
happening
rather
than
hoisting
them
up
into
the
beacon
chain.
I
don't
feel
super
strongly
about
this
mikhail.
You
put
up
the
pr
for
the
256
version.
Would
you
like
to
comment.
L
Yeah
sure,
yes,
danny,
said
that
this
field
has
been
introduced
by
basin
with
london
and
yeah.
When
I
was
doing
this,
I
was
like
thinking
that
you
end
would
be
pretty
much
enough
in
general
case,
because
it's
hardly
to
imagine
that
that
we
will
see
base
fee
for
gas
like,
let's
say
38th,
which
is
really
crazy
number.
L
But
then
proto
pointed
out
that
during
the
transition
process
it
might
be
valuable
attack,
though
the
cost
of
attack
is
relatively
high,
but
it
depends
on
the
different
conditions,
and
so
we
need
to
reason
about
it.
And
ideally
we
don't
want
to
reason
about
it
at
all.
So
that's
why
this
pr,
I
agree
with
option
to
use
bytes32,
but
since
we
would
like
to
move
more
checks
from
the
execution
layer
to
the
consensus
layer
or
at
least
duplicate
them
here
for
different
reasons,
it
might
mean
that
which
is
differing.
L
L
J
L
L
A
L
M
M
Right
and
so
in
order
to
calculate
the
base
for
the
correct
basis
for
gas,
you
need
the
full
set
of
transactions
for
the
parent
block,
which
is
fine
if
you
already
have
it,
but
I
definitely
wouldn't
want
to
make
you
guys
have
to
make
the
says.
Clients
have
to
start
tracking
all
that
just
so
they
can
do
this
validation.
The
execution
class
is
going
to
be
you.
M
Okay,
just
just
so,
if
we
go
down
this
path
of
having
this
client
do
more
checks,
there's
pros
and
cons
there
in
general.
So
the
pro
is
that
we
have
even
more
things
that
are
validating
consensus,
which
is
good,
so
the
more
diversity
and
code
we
have
the
more
likely
it
is
that
we're
gonna
catch
bugs
before
mainnet.
The
obvious
downside,
of
course,
is
if
we
now
have
eight
clients
doing
the
exact
same
check.
There
is
a
higher
chance
that
one
of
them
will
get
it
wrong
and
we'll
have
a
consensus.
M
A
Even
when
I
was
looking
at
the
london
rebase,
I
was
certainly
unsure
of
the
base
fee,
calculation
being
hoisted
the
correctness
calculation
being
hoisted
in
the
consensus
layer.
I
don't
see
much
value
in
doing
that,
as
maybe
ever
especially
if
it
requires
the
introduction
of
the
un-256
computational
type,
which
we've
attempted
to
avoid,
but
we
also
made
that
decision
literally
years
ago,
so
we
could
certainly
revisit
the
decision.
M
A
M
The
I'm
just
going
to
throw
this
out
there.
I
don't
necessarily
think
it's
a
good
idea,
but
just
to
brainstorm,
we
could
check
to
see
if
it's
reasonable
to
have
the
execution
client
just
cap,
that
into
q64,
like
that's
a
big
enough
number,
that
it's
like
a
significant
percentage
per
gas
of
the
entire
supply.
M
M
M
L
A
Right
but
that's
there's
two
sides.
The
argument
one
is:
is
the
unnecessary
computational
requirement
and
then
the
other
is
the
introduction
introduction
of
a
different
type
of
type
and
potentially
library
which,
if
you're
just
doing
one
thing,
is
an
argument
for
avoiding
the
introduction
of
that
additional
complexity.
A
K
J
M
But
that
brings
in
a
yet
another
dependency,
which
you
know
when
you're
worried
about
supply,
chain,
attacks
and
stuff.
One
more
dependency
is
just
one
more
attack
vector
it
also.
You
know
there's
some
of
those
dependencies.
You
know
they
function
but
are
not
great.
Like
I've
used
some
of
them
and
it's
painful
in
some
languages,
some
languages
are
good
like
they
integrate
really
well,
especially,
if
you
have
opera
operator
overloading
your
language,
then
adding
new
integer
types
is
fine.
If
you
have
no
operator
overloading,
then
you
know
your
code
is
just
uglier.
M
I
A
A
Let's
just
we
move
on
to
the
next
item,
which
is
merge,
related
client
security
settings.
I
don't
know
if
that's
the
appropriate
way
to
call
them.
Essentially
some
specified
cll
cli
arguments
for
handling
exceptional
scenarios
in
the
event
of
merge,
so
minor
attacks
or
all
sorts
of
other
things.
These
would
be
used
to
socially
coordinate
against
exceptional
scenarios
to
kind
of
force.
The
merge
through
in
the
event
that
our
our
code
logic
doesn't
exist.
A
You
can
see
an
open
issue
where
we're
discussing
this
there's
two
discussion
points.
One
is
what
are
these
parameters
and
the
two
is
actually:
where
do
you
specify
these
parameters?
I
think
you
could
do
merge
clientsettings.md
another
markdown
file,
there's
a
bit
of
a
precedent
for
this
in
eip1011,
which
was
the
hybrid
proofwork
proof
of
stake.
A
We
had
some
client
settings
that
were
specified
so
that
social
coordination
and
the
event
of
attacks
was
treated
as
kind
of
first-class
citizen,
so
mainly
just
wanted
to
bring
this
up
so
that
you
can
take
a
look
at
it
and
also
to
hear
any
feedback
about
these
settings
actually
being
specified
in
the
in
the
spec
like
they
are
they're
kind
of
like
security,
related
client
settings
that
probably
everyone
should
implement
if
they
end
up
in
the
in
the
core
specs.
Is
that
a
reasonable
place
to
specify
these
things?
I
A
M
Yeah
yeah,
so
I
agree
with
adrian
that
keeping
within
client
consistency
in
the
naming
is
probably
the
most
valuable
thing,
but
it
definitely
would
be
nice
from
a
support
standpoint
if
the
clients
all
use
like
the
same
words
and
like
if
one
does
camel
case
other
one,
the
snake
case
is
going
to
have
hyphens,
then
you
know
we
can.
Whoever
is
supporting
your
users
can
easily
adapt
when
the
names
are
just
totally
unrelated,
though
it
becomes
much
more
difficult
to
keep
track
of
okay.
What
was
it
that
this
particular
client
used?
I
A
Okay,
well,
we'll
continue
the
discussion
about
the
couple
of
settings
that
might
be
useful
in
the
event
of
exceptional
scenarios
around
the
merge
and
work
on
a
common
way
to
be
able
to
specify
these
within
the
two
specs
repo,
which
I
think
will
be.
You
know,
fork
slash
client
settings.md,
and
we
will
also
revisit
a
few
of
the
settings
that
we
decided
many
years
ago
that
were
valuable
for
1011
that
were
not
they're,
not
really
commonly
supported
and
probably
should
be,
and
maybe
get
those
into
this
spec
as
well.
A
K
A
K
A
And
just
some
quick
background,
the
bls
tests
that
are
built
against
the
spec
kind
of
evolved
out
of
necessity
as
we
waited
for
official
ietf
vectors.
It
doesn't
make
sense
for
most
of
them
to
live
so
tightly
coupled
to
our
spec
and
are
end
up
being
less
useful
for
others
that
just
want
to
use
these
libraries.
So
now
they
exist
somewhere.